The road to 0.2.8.2

[Luke-Jr]

My guess for the sake of the argument would be that most of those who got the versions right don't read explanations, either

Well, they they got the first one right by coincidence and didn't (won't) get the new one right. Either way, 2.9.0 is still > 0.2.8

z-man prefers 0.x.y version numbers (as a matter of taste)

Somewhat irrelevant (matters of taste), even if true. AFAIK, z-man has never said anything of the sort and the fact that all the past releases have been 4-integer style suggest he would prefer that in taste.

next version is 0.2.8.2 because we like to have some more number till 0.2.9

Version integers have meanings, and it's pointless to make them mere numbers as this suggests.
There is nothing special about 0.2.9. We can always release 0.2.10 and 0.2.11, etc...

However, we're nominally working towards 1.0 for various reasons I don't really want to sum up (search the forums for it ).

However, this first integer is merely a "completeness factor" and is really a boolean value, thus less relevant than the rest.

ANd it'll be Major.Minor.Revision, where Revision usually means bugfixing, but there's some lingering discussion about backporting.

We have had plenty of major version increments thus far, and the next stable will be yet another release introducing major changes. The currently decided method is effectively Completeness.Major.Revision (where Revision is bugfix for stable and artificial for experimental)-- somehow we managed to drop "Minor". Maps are not a minor change, nor are multiple fields and the like.

So that makes 0.2.8 the last stable release before 1.0. What we didn't settle was how we were going to partition up releases from the stable branch that is Artemis, which is 0.2.8. Seems to me like it should be partitioned as 0.2.8.x, and we'll just wrap from 0.2.8.9 to 0.2.9.0. Some folks around here hate that, but realisticaly it gives us 20 releases before we have to either break that pattern or retire the 0.2.8 series.

Carrying version increments is flawed and removes the meaning from the integers, while also encouraging people to think of the version as a decimal number, which it isn't.

I think Bacchus will be out the door before we do 20 releases on the 0.2.8 line.

Who said 0.2.8 is unmaintained when Bacchus is released? Especially if we move to something like darcs, where it would be fairly simple to apply all bugfix patches to any number of past releases without manual merging...

To summarize: Versions are not decimal numbers and should never be treated as such. When deciding a new version scheme, we somehow neglected the possibility that we might want to do minor feature increments and dropped the Minor integer. Since it is obvious some people want such increments, it should be introduced. If four integer versions are too many parts, Completeness is the least useful in a practical manner.

[Lucifer]

*Conspicuously not taking the discussion about version numbers farther than it needs to go for a decision that's already made*

So, the only question I see as far as version numbers goes is the suggestion that we bump up to 0.2.9. Why not just stick with 0.2.8.2? Since there's a huge versioning overhaul happening after this, what's the big deal? We just need to show what the latest stable release is, right?

[Luke-Jr]

*Conspicuously not taking the discussion about version numbers farther than it needs to go for a decision that's already made*

Decisions made can and should be changed when they are found to have flaws. In this case, the decision has not even been implemented, so it would be an easy change.

So, the only question I see as far as version numbers goes is the suggestion that we bump up to 0.2.9. Why not just stick with 0.2.8.2? Since there's a huge versioning overhaul happening after this, what's the big deal? We just need to show what the latest stable release is, right?

The suggestion is to split what is right now to-be-0.2.8.2 into two separate groups: 0.2.9.x (where x is 0 or 2) containing new features (not only current new features in 028-branch, but potentially a few more) and 0.2.8.2 (which is bugfixes only, as originally planned)

[Luke-Jr]

Another potential solution:
Continue the 0.* releases as Completeness.Major.Minor.Revision and when we deem ready for 1.0, move to Major.Minor.Revision resetting Major to 1.
Thus,

0.2.8.0 (0.2.8 "final")
0.2.8.1 (first bugfix-only release to 0.2.
0.2.8.2 (second bugfix-only release to 0.2. and 0.2.9.0 (minor feature increment from 0.2.
0.2.8.3, 0.2.9.1, 0.2.10.0 (minor feature increment from 0.2.9)
0.2.8.4, 0.2.9.2, 0.2.10.1, and 0.3.0 (first experimental 0.3 release)
0.2.8.5, 0.2.9.3, 0.2.10.2, and 0.3.1 (second experimental 0.3 release, adding any number of features)
0.2.8.6, 0.2.9.4, 0.2.10.3, 0.3.2, and 0.2.11.0 (someone found more minor features to add)
(no 0.2.8.7 because it was unaffected), 0.2.9.5, 0.2.10.4, 0.3.3, and 0.2.11.1
(only 0.2.10+ were affected here), 0.2.10.5, 0.2.11.2, and 0.4.0.0 (major feature additions made throughout 0.3, but not ready for 1.0 after all)
0.2.10.6, 0.2.11.3, 0.4.0.1, 0.4.1.0
0.2.10.7, 0.2.11.4, 0.4.0.2, 0.4.1.1, and 0.5.0
0.2.11.5, 0.4.0.3, 0.4.1.2, and 0.5.1
0.2.8.7, 0.2.9.6, 0.2.10.6, 0.2.11.6, 0.4.0.4, 0.4.1.3, 0.4.2.0 (some minor features from 1.0), and 1.0.0
0.2.11.7, 0.4.0.5, 0.4.1.4, 0.4.2.1, and 1.0.1 (bugfixes to 1.0.0)
0.2.11.8, 0.4.2.2, 1.0.2, and 2.0 (first experimental leading to 3.0)
0.2.11.9, 0.4.2.3, 1.0.3, 2.1 (second experimental), and 1.1.0 (minor features added to 1.0)

Of course, having an experimental '2.0' looks a bit strange, so we could drop the whole even/odd stuff and just say "2.0_preX" for experimentals leading up to a stable 2.0.

Note: Of course, maintaining as many versions as depicted here is utter insanity if we move to anything less capable than darcs with regard to merging. In which case, I can see the argument for "screw maintaining releases older than the latest stable" which leads to "minor features can go into stable revisions" since any version increment would lead to the formerly stable version missing the bugfixes as well as the features. So I guess that leaves three options to consider: 1) keep minor increments in expectation of darcs-style merging capabilities "soon", 2) maintain-latest-stable-only until we get such capabilities, 3) ignore such capabilities even once/if we get them

[Z-Man]

Decisions made can and should be changed when they are found to have flaws.

Every solution has some flaw. We're just refusing to comment AGAIN on those of your old suggestion (hint: try to get 0.2.10 < 0.2.9 OUT of peoples heads). The major flaw of your new suggestion is that every release is tons of work and stress for the one managing it, and splitting minor features from bugfixes without actual need creates new releases to manage. Your de facto release manager and primary builder won't accept that.

[Luke-Jr]

Decisions made can and should be changed when they are found to have flaws.

Every solution has some flaw. We're just refusing to comment AGAIN on those of your old suggestion (hint: try to get 0.2.10 < 0.2.9 OUT of peoples heads).

I think most people will get the idea when 0.2.10 is released after 0.2.9.

The major flaw of your new suggestion is that every release is tons of work and stress for the one managing it, and splitting minor features from bugfixes without actual need creates new releases to manage. Your de facto release manager and primary builder won't accept that.

Like I said, it is insane without darcs-style merging. It might also be insane for binary releases unless they are automated (which should be possible once something is stablized). But hopefully we can manage those two. Even if we don't get automated compiling, we can continue to put out source-only bugfix releases for older stable versions.

[Z-Man]

My lack of comment to 0.2.10 doesn't mean I agree with Luke, it just means I want to avoid repeating myself and, more importantly, avoid Luke from repeating himself

To most of our users, source only releases are of little use. Compiling is already largely automated; I can push up a Linux build and source release whith "make blarg; make z-man-home; make upload-aabeta". Windows could be automated with switching to cross compilation and building the installer with Wine. But the building isn't the problem. The testing is. You can't call something a release without running tests, and I mean tests on different operating systems here. The SF compile farm may be of help, but last time I checked, all hosts were running terribly outdated software, limiting us to server tests at least, but also those didn't work because libxml2 was too old, and we don't have root rights so we can't do a full test. So testing on different OSes means actually booting them on your PC, doing the installation, and running the game.
Then, if there is a release, it has to be uploaded to the SF file release system, which can't be automated and is hell. Release notes need to be written and copied. Around a release, much more needs to be done than just "make dist", and most of it is fundamentally unautomatable. I'm happy about suggestions to drive automation as far as possible.

My current way out of this is what you see here: push out alpha builds before something is even called beta or a rc. I don't have to test those, and only do the compatibility tests and relabel the release after none of the voluntary testers was blown to bits.

[Luke-Jr]

To most of our users, source only releases are of little use.

Most of our users would be using the latest stable or latest experimental. Those who are outside of this group can manage with sources if nothing else is available.

Compiling is already largely automated; I can push up a Linux build and source release whith "make blarg; make z-man-home; make upload-aabeta". Windows could be automated with switching to cross compilation and building the installer with Wine. But the building isn't the problem. The testing is. You can't call something a release without running tests, and I mean tests on different operating systems here.

Once a version has reached the stabilizing point, it should only be getting bug fixes. Bug fixes should never be expected to break something, thus there is no need for real testing on such releases provided the bugfix is tested as part of a concurrent release of a more recent version. For example, if the bugfix is going into both 0.2.8 and 0.2.9, it really only needs to be tested on 0.2.9 to be 99% sure it's a safe change.

Then, if there is a release, it has to be uploaded to the SF file release system, which can't be automated and is hell. Release notes need to be written and copied.

We're getting away from SF, remember? I don't think anything other than the latest stable and experimental really need the SF mirror backbone...

Around a release, much more needs to be done than just "make dist", and most of it is fundamentally unautomatable. I'm happy about suggestions to drive automation as far as possible.

Most of this stuff only applies to a release that is not bugfix-only, such as a new stable or experimental version.

[Z-Man]

We're getting away from SF, remember? I don't think anything other than the latest stable and experimental really need the SF mirror backbone...

While you're arguing that a pure bugfix release doesn't need all that fancy stuff (building, testing, writing release notes, fast downloads over sf mirrors, management, support) we throw at a normal release, why don't you go all the way and tell those two users who don't want the completely harmless featurelets that are off by default to bake their own version from our SCM? This would save us (mostly me) a lot of trouble, and by your argumentation, wouldn't be any less stable.

[Luke-Jr]

True