1.0.3 release > 1.0.3.2 beta, correct?

sy
syclone
Posts: 54
Joined: Sat Aug 13, 2011 5:15 am
Platform: Windows

Wed Nov 30, 2011 3:03 am Post

Lee (if I may call you that), I'm a little confused on the version numbering convention. I've read through the post http://www.literatureandlatte.com/forum/viewtopic.php?f=34&t=16331#p114185 in which you gave us the decoder ring but I'm not entirely clear on how the beta digit works. If I remember right, 1.0.3.2 (the fourth digit representing a beta-level release) came out before 1.0.3 official release.

Unless I am interpreting the description wrong, and I apologize for taking yours and others' time if I am, the current scheme could cause confusion. Right now, from the "Beta Testing (Windows)" screen, it look as though a beta that supercedes 1.0.3 (i.e., 1.0.3.2) is available for testing. But as I understand it, 1.0.3 is the greatest, with no betas beyond it available as of this writing. Looking at dates and reading the text in the posts would surely clarify which is newest (not to mention the download link provided on other pages); however, initial confusion would be understandable.

Hypothetically, prior to moving from version 1.0.3 to 1.0.4, would that round of betas start at 1.0.3.1 or 1.0.4.1? It's looking to me like the latter. I'm sure some things are set in stone by now but may I suggest adding the fourth (beta) digit, to the existing software's three-digit set rather than the forthcoming's set; or maybe using alpha characters to indicate beta level, for example 1.0.3.a or 1.0.3a. (However, in any event, alpha or not, I believe that the pre-upgrade numbers would be most logical to use.)

Thanks for allowing us to post suggestions and I'm sure there is plenty you are working on so please view this as nothing more than free advice for good or bad. :)

User avatar
robertdguthrie
Posts: 3075
Joined: Mon Nov 09, 2009 10:06 pm
Platform: Mac
Location: St. Louis, MO, USA
Contact:

Wed Nov 30, 2011 2:26 pm Post

I think this is telling from the linked page:

"On to this beta for 1.0.3.2 which has all the fixes listed for 1.0.3 plus the following two updates:"

Here, you see that 1.0.3 preceded the new beta 1.0.3.2, so from that you can draw the conclusion that the progression is:

1.0.3 -> 1.0.3.1 -> 1.0.3.2 ... -> 1.0.4 ...
Often wrong, rarely in doubt.
Time for a change... I'm now rdale; same dog-avatar, same dog... channel?

sy
syclone
Posts: 54
Joined: Sat Aug 13, 2011 5:15 am
Platform: Windows

Wed Nov 30, 2011 6:19 pm Post

Got it. Version 1.0.3.2 has all the fixes contained in 1.0.3, in addition to new beta-level changes-- which is a typical syntax. Because of the release dates for the subject versions, it appeared the other way around (that beta 1.0.3.2 was merely last minute testing for changes intended to be included in release 1.0.3) and the syntax swould have been counter intuitive.

If this is all true then 1.0.3 was apparently just still being readied for its release after beta version 1.0.3.2 was made available for testing; therein lies my confusion (added to the fact I missed the sentence robertdguthrie pointed out, above). Beta release seems to have been one step ahead of the current non-beta release.

So my subject title to this post is in fact not correct, 1.0.3 < 1.0.3.2 is how it should read. Sorry for any troubles all. It did help to clarify this in my head though.

User avatar
MimeticMouton
Posts: 8868
Joined: Wed May 05, 2010 5:39 am
Platform: Mac + Windows
Location: city of rain
Contact:

Thu Dec 01, 2011 4:11 am Post

No...it's the other way around...you were correct initially. 1.0.3 > 1.0.3.2. The extra number on the end indicates that it's a beta version, and that number will increment for the betas of that version up to the next release. So next we'd see 1.0.4.1 as the beta for the (not-yet-released) 1.0.4 version, and so on. Once the betas are gone through and Lee's comfortable releasing, then the "beta" tag on the end is removed and 1.0.4 comes out and that is then the newest.

So the official 1.0.3 version that was released on the 26th is the most recent version available; there have been no beta releases since then.
Jennifer Hughes
(MM for short)

ji
jinchoung
Posts: 94
Joined: Wed Nov 02, 2011 11:30 pm
Platform: Windows

Sun Dec 04, 2011 10:08 am Post

yikes!

that's counterintuitive.... my expectation is that 1.0.3 comes out... and then the beta versions will go

1.0.3.1, 1.0.3.2, 1.0.3.3 ... 1.0.3.9, 1.0.4, etc.

and i would imagine most people will NOT read the readmes about the numbering and just assume the same.

just gonna throw this out there - you're probably gonna see this topic getting revisited again and again... : []

jin

jr
jravan
Posts: 212
Joined: Fri Apr 08, 2011 2:15 pm
Platform: Windows

Sun Dec 04, 2011 6:54 pm Post

Warning: This is a pretty technical, software developer, type of reply. If you don't care about technical software development details, you needn't read further.

In his post, http://www.literatureandlatte.com/forum/viewtopic.php?f=34&t=16331#p114185, outlining the Windows version numbering scheme, Lee posts his "version taxonomy":

VERSION_MAJOR = 1
VERSION_MINOR = 0
VERSION_PATCH = 3
VERSION_BETA = 2 e.g.'1..n' to specify beta or '0' for normal release.

Above, syclone suggests using alphas instead of integers, so as to eliminate the "1.2.3 > 1.2.3.4" issue. I would like to formalize that somewhat and present a slightly different taxonomy that doesn't have the "x > x.y" problem and also allows for "forking."

First, let me explain the "forking" problem. Assume that version 1.2.3 of a software product has been released. Work begins on the next version. It will contain bug fixes and minor features. While development proceeds, a priority 1 showstopper bug is discovered in version 1.2.3, for example, it crashes the user's machine and erases work in progress. An engineer finds and fixes the bug. Given the severity of the problem, the decision is made to immediately release version 1.2.3 patched with only this one additional bugfix. The question: "What is the version number of the P1 bugfix release?" Well, one might assume that the development work that was already underway would have been called 1.2.4 internally already, and perhaps there are already build procedures that have been updated to produce 1.2.4 test versions. And perhaps documentation on the fixes and features in 1.2.4 has already begun. Changing that is also more work. So it would now be difficult to get this new patch release built and call it 1.2.4. But that is what users would expect--version 1.2.4, patch level 4 of version 1.2, fixes the crashing bug.

This is the forking problem. One set of work should continue creating the next release while the company remains able to release any number of patches to existing released software. This is called forking because when one diagrams issues like this, the drawings contain lines of development that diverge, that create "forks."

Developers handle this problem in many ways. syclone suggests one. Let me formalize his suggestion slightly to fix the "x > x.y" problem and allow release forking. So, assume that Lee's taxonomy remains intact. The only thing we will do is increase the semantics of what a VERSION_BETA actually is:

VERSION_BETA = {"a" | "b" | "rc"} <integer>

What this says (in a language called BNF) is that whenever VERSION_BETA is used, it must consist of one of the strings "a", or "b", or "rc" and a number. That's all. Released patch versions are simply numbered incrementally with a VERSION_PATCH. VERSION_BETA is optional. In the example above, if version 1.2 patch level 3 has been released, then the next patch to version 1.2 must be patch level 4. Also, before 1.2.4 is released, it goes through testing, from alpha testing ("a1","a2",...), beta testing ("b1","b2"...), and release candidate testing ("rc1","rc2"...) by using VERSION_BETA labeling. And how does that handle the forking problem? In this scenario, developers would not have begun work on 1.2.4 after 1.2.3 was released. They would have begun work on 1.3.0. The developer's initial patch to the existing 1.2.3 problem would start testing internally as 1.2.4.a1, 1.2.4.a2 (etc...). Eventually it would be built and tested by the beta community as 1.2.4.b1, 1.2.4.b2 (etc...) and the final release candidates would be numbered 1.2.4.rc1 (etc...). When the patch for the crash is released, the version is labeled 1.2.4. I think this eliminates the 1.2.3 > 1.2.3.1 issue simply because VERSION_BETA is not a number.

Some folks may be thinking "But that only gives us 9 minor versions." I'll relate something that happened to me early in my software career. The company had released version 1.5 of the product I was working on. I was working on version 2. They wanted to release version 2 earlier than originally planned, but were convinced (by us software types) that the functionality had to be reduced to make the new schedule. But the marketing types then forced us to call it version 1.75 because "that's much closer to 2 than 1.6." But in software version numbering, each number in the dotted n-tuple increments independently. So the version after 1.9 is 1.10.

ji
jinchoung
Posts: 94
Joined: Wed Nov 02, 2011 11:30 pm
Platform: Windows

Mon Dec 05, 2011 1:34 am Post

yikes again...

must it be so complicated?

couldn't it just be that 1.0.3 is released.

they start working on 1.0.4 with bug fixes and minor features.

they find show stopping bug.

the fork is simply 1.0.3.Patch01 ?

the biggest thing is that inasmuch the version numbers will be relevant to users who are not developers, the numbering system should just be intuitive and not require documentation.

game devs do rolling revisions as well but they've never had to document which version is greater than another. you just get it cuz everything's going up.

jin

User avatar
narrsd
Posts: 718
Joined: Wed Sep 22, 2010 8:34 pm
Platform: Win + iOS

Mon Dec 05, 2011 2:07 am Post

Thinking Jin is right on this one.

1.03 release should have only bug fix _advances_ as 1.03.1, etc..

There''s no limit to how many bug fixes, as the suffix isn't limited to .9 -- can go to .10, .11, etc.

1.04 should be the next release coming. Any bug fixes from 1.03 ongoing ought to be folded into 1.04. 1.04 can have as many _beta_ versions prior to release as needed, named as 1.04b1, 1.04b2, 1.04b99 etc..

In other words, no user should be confused by having to load a version with a smaller number to get the latest.

Hope I've got my own hat on straight this evening...

Clive
Last edited by narrsd on Tue Dec 06, 2011 2:43 am, edited 1 time in total.

jr
jravan
Posts: 212
Joined: Fri Apr 08, 2011 2:15 pm
Platform: Windows

Mon Dec 05, 2011 3:53 am Post

couldn't it just be that 1.0.3 is released.
they start working on 1.0.4 with bug fixes and minor features.
they find show stopping bug.
the fork is simply 1.0.3.Patch01 ?

If the fork is labeled 1.0.3.Patch01, then ".3" is not a VERSION_PATCH, it is a VERSION_MORE_MINOR. If it really is a VERSION_PATCH, then let's only make patches when that number increases.

The details I gave are internal to the software developers and beta testers. Paying customers only see new features and fixes folded into major.minor.0 releases and patches folded into major.minor.patch releases. Simple. In other words, this workflow makes MAJOR mean major, MINOR mean minor, and most importantly, PATCH mean patch (not "next release with more features").

they start working on 1.0.4 with bug fixes and minor features.

The next planned feature/functionality releases would always be major_number.last_minor_number+1, not major_number.minor_number.last_patch_number+1. So if they start working on the next version after 1.0.3, that should mean two things:

  • version 1.0 has been patched three times
  • the next feature release will be 1.1.0
The patch number only gets updated if an actual change is made to the existing released version to fix a bug (not a feature enhancement). Otherwise, VERSION_PATCH doesn't mean patch, it comes to mean "next feature release."

must it be so complicated?

I think the suggested changes make it easier, not more complicated. Feature releases are always x.y.0. That's it. It might be more correct to call it "accurate," that is, it reflects the actual software development workflow. Is the issue with having "a" mean alpha release, "b" mean beta release, and "rc" mean release candidate? Because that is what happened to the Windows beta. We just weren't labeling them with those names (though, obviously, I think we should have. Those tags have meaning.) Or is it something else? And I believe that every release, beta or otherwise, gets a new release number. Integers are cheap.

In other words, no user should be confused by having to load a version with a smaller number to get the latest.

Is the issue here that a user might be testing x.y.0.b3, but a bug has been patched in the previous released version x.y-1.0? Let me make the numbers concrete. The developers are working on version 3.4.0. They have started external beta testing and are up to 3.4.0.b6. Then a bug is found in the previous release, 3.3.0. They would like to fix that bug and beta test it, independently of the beta testing on 3.4.0. They must not just fold the bugfix into 3.4.0.b7 and call it a day. Existing users of 3.3.0 would not want to have to beta test the new features in 3.4.0. Those new features are still buggy. They only want to test the bugfix to 3.3.0. They can do that only if the company allows them to "load a version with a smaller number to get the latest." And only for a particular definition of "latest", one that means "latest patch release during beta testing of a feature release." Assume that sometime later 3.3.1 (the patch release that fixes the bug in 3.3.0) is approved for release before the beta for feature release 3.4.0 is complete. Even in that case, there is no version in the field (other than to beta testers of 3.4.0) that is higher than 3.3.0. So, 3.3.1 is really still the highest version number of released for revenue software.

Lee has said that the last number in the numbering scheme is VERSION_PATCH. If that's true, then I suggest that calling it VERSION_PATCH means "only changes that fix bugs." With the knowledge that those bugs also get fixed upstream in the next major.minor.0 release. And .0 means "ain't got no patches yet." I think that's pretty simple.

I think one hangup might be that this is not the way we do things now. x.y.z+1 is the way we do things now. VERSION_PATCH does not mean "patches only" right now. Yes, this is different, but I think it's simpler. And cleaner.