Versioning strategy

versions

#1

Hi,

I want to discuss with you our versioning strategy and possible change to new.

Currently our strategy is: AppName_<Major>.<Minor>.<Patch>.<BuildNo>

[details=Summary]Major - Major version is a definite release of the product. It increased when there are significant changes in functionality. I planed to show by this number that the project mature enough and cover all basic functionality.

Minor - Minor version is incremented when only new features or major bug fixes have been added.

Patch - Patch version starts with 0 and incremented only when bug has been resolved.

Build No - Build Number represent commits number past after last release.[/details]

This is good strategy, but according to my observations it doesn’t perfectly suit our purposes.

Major - Major version is a definite release of the product. It increased when there are significant changes in functionality.

According to our speed and number of changes at least versions 0.4.0 and future 0.5.0 could be major. These are significant releases for us. And because many users already use Valentina for making product ready patterns awaiting release 1.0 has less sense that it was at the beginning when i decided which versioning strategy to choose.

I don’t like stupid marketing, but as you maybe mentioned many users say v4 or v5, v4.5 instead of v0.4.5. Even i see that this is much more comfortable.

So, new strategy could be:

AppName_<Major>.<Minor(left empty)>.<Patch>.<BuildNo>

Description is almost the same as for the previous strategy. But each current minor release become major and minor number is not used anymore.

For example 0.5.0 will be 5.0.0. Next release with bug fixes will be 5.0.1, 5.0.2 and so on.

So, what do you think?


#2

You make a good point. However, it implies that the software has reached the set of features needed for use as a full patternmaking software tool. I will be talking with people next week who are using Valentina in their business. We want businesses to contribute to ensure that Valentina becomes what they need. We need their financial support, and 5.0.1 sounds like stable full product. For this reason, I would like to keep the current versioning system. Yes this is also marketing :slight_smile:


#3

Good. Less work for me.:wink:


#4

Have you given thought to making a stable interface so that any pattern file created with one version of the valentina program can be opened with any newer version of the program? I believe that this is important. For major versions this is critical. An older pattern file should never cause the newer program to fail. This concept is referred to as “backward compatibility”

Are there technical issues to prevent this?


#5

by the way, many of Leena’s patternmaker macro files created with version 6 will crash the version 7.5 patternmaker program. They probably crash the version 7 as well, I am not sure. I still believe it is bad practice


#6

I think i did quite good job if you did not understand that there is such mechanism.:wink: It called IFC (internal file converter). Each time Valentina opens a file it checks file’s version and convert it to newest if need. This mean Valentina always works only with the latest version it knows. There is also no return to older versions. You can’t save in old format.

We do not change format in stable branch.

That user had old test version and that’s why he could not open the file.


#7

Hello,

Personnaly, knowing Valentina, I don’t care.

But : For my needs, as I’m not doing clothes, and as I deal with quite complex patterns, Valentina is still far from being usable in production. I see many good things, and the whole project if more than promising, but its lacks are too numerous.

WIth the current naming, I knew before downloading it that it’s still at early stage. And I wasn’t expecting too much from it, and finally, I have only good surprise.

Having a version called 4.5 would maybe let me think that it was already greatly advanced, and could have lead in deception.

So it could be the same for others people with my profile. So better keep the current system?


#8

Production needs can be very different.

I hope you are not new to open source and communities around them. And know how they work.


#9

I like the concept of the IFC and of course I think you have done quite a good job, and the Valentina program is excellent.

I had great respect for your abilities simply based on the program and reading in the forum. Since meeting personally with @slpencer yesterday, my respect for you both has only increased.

I understood that the user had an old test version. I have reproduced the issue myself.

I still do not understand between why it should not be possible to open the pattern file. Is there some technical reason that the pattern file format is not compatible between minor versions in the test code?

Does the file format actually change, or is there simply an arbitrary software check that shows the error? Do you have the “severity” concept for errors? By this I mean for a trivial error would you issue a warning message and continue?


#10

Dismine, no worry, I know how it works. I can’t help much as I’m not developper, but I’ll keep on testing and give my feedback. I also finished the french translation on Transifex (not much work, there were only 15 sentences left :slight_smile: ) I’ll try to help according to my possibility.

And do not take my sentence out of context. I said “For my needs…it’s far from being usable in production” Only for my needs. I deal with complex patterns (around 300 pieces, with a lot of linked pieces and very long tuning process, which means tons of modification on patterns, before the final version), but I see a great potential in Valentina.

And I already recommanded it to friends who makes clothes, as there is simply nothing similar.(traditionnal patterning solutions are just out of reach for small businesses).

Again good job, congratulation !


#11

Personally i don’t care why. These are test builds. Maybe i missed tag in XSD schema or decided not to update format version and Valentina stops parsing on validation stage instead of saying that new version is unknown.

My current policy is to update format version each time i share my changes publicly, even for test builds. I don’t care about quick growing numbers. Any change should have own version. This approach has many advantages. This is evolutionary model. And because we own our format we don’t care about outside applications that should also support new versions.


#12

@dismine, I apologize if you think I am wasting your time. I do not mean to do so. I spoke with @slpencer yesterday on the subject of beginning to create a test suite that could be used in the future before new major releases. Version 1.x.x.x would be an example of a major release. This is not something that you personally would need, or certainly not soon.

@slpencer The term I would use for the testing that is done currently is what I would call “alpha” testing. I have seen the term “beta” testing used in a more formal process. This is not a value judgement on my part, I am simply trying to agree on language to describe what exists.

I would expect that a version number will predict something like the portability of a pattern file. Referring to your numbering scheme

AppName_.<Minor(left empty)>..

I would expect to use a pattern file created by 0.4.x.x with any program 0.4.x.x with no problem.

If I understand the IFC concept, any file created with a program earlier than 0.4.0.0 would need to be processed by IFC and would then be usable by a program 0.5.x.x

These are test builds. Maybe i missed tag in XSD schema or decided not to update format version and Valentina stops parsing on validation stage instead of saying that new version is unknown.

I believe you are doing excellent work. I simply want to know whether I need to ignore all pattern files created with a version earlier than 0.5.0.0.


#13

Yes, i think so.

Not only with 0.4.x.x, but any later versions.


#14

Not only with 0.4.x.x, but any later versions.

yes. that is what I meant by the term backward compatible. I believe your IFC is the way that you implement backward compatibility. good job

I would never expect a program version 0.4.x.x to work with a pattern created by a later program version 0.5.x.x That would require a time machine or supernatural intuition.


#15

Actually 0.5.0 can try to open newer version. It just try to validate a file even if it has newer version and if validation will be successful (for example you did not use nothing new if a file) it will open a file.


#16

That is great and an unexpected feature. But if Version 0.5.0 program were to encounter a pattern created by version 0.6.0 software nobody could assign fault to a developer if the Version 0.5.0 software displayed an error and quit.


#17

That is what I meant by my comment about a time machine. Though it could happen in the real world if users were exchanging patterns and they did not both update their software at the same time.


#18

If I sounded critical at the beginning of this thread it is because I expect a Version 0.6.0 program to handle ANY thing that a Version 0.5.0 program might have put into a pattern file. And I realize that might not always be the case in development at very early stages. That supports what I believe @slpencer referred to when she said

I will be talking with people next week who are using Valentina in their business. We want businesses to contribute to ensure that Valentina becomes what they need. We need their financial support, and 5.0.1 sounds like stable full product. For this reason, I would like to keep the current versioning system. Yes this is also marketing :slight_smile:

the versioning (0.5.0 as opposed to 5.0) is a way of managing the expectations of the user