revs and releases

[EdB]

First off this comes up from over here viewtopic.php?f=6&t=917

What about this: Snapshots/development versions have version numbers of the form "${final_version}-r${lp_rev}", i. e. if we are going for version 1.0.0, development releases of that version would have version numbers like "1.0.0-r7624". The final release would automatically get "1.0.0".

The advantage of a scheme like this is that it would work somewhat nicely with version_compare(), which many plugins use to query QP's/b2evo's version in order to decide how to function.

Okay, so 0.0.0 was more like a joke, you know? 0.0.0 as in "Ground Zero", our starting point where we would have a solid base to work with. I have absolutely no problem with increasing the version. Not sure if we should already go for 1.0.0, but maybe?

Good, about version numbers... I don't know, just using one number looks funny to me. Of course, that's subjective. It would lead to pretty big version numbers... What about using just two components? Like 1.0, 1.1... First digit is the major release (big changes), second number is for stuff like security fixes, minor updates...

Okay. So I got to thinking from the other thread and had a thought that might be new. We kicked around release schedules and versioning numbers till the cows came home and still don't have anything.
First up is a release schedule.
We have ONE release in 9 months, and no firm clue on when the next will be. "Wait for app_nonces" is a joke IMHO because look at the activity on that branch. Might as well just say that 0.0.0 is the only release we'll ever bother having eh? But what does trigger a release? I have and will again propose something very simple: time. Every 4 months we package an official release.

• We have committed to not merging branches that break the product, so selecting a date and saying "this is it" (a) won't cause a crap release to happen, and (b) might motivate us to get our last branches reviewed and merged in before the big day.
• The "your app is getting old" thing might then actually be useful in that we would know there was a new release if their app is 6 months old.
• Nightly snapshot should always be the thing we call a release by the way.

Second up is the release number.Yeah 0.0.0 was a bit of a joke, but now that it is over let's please not do that. In the quote above Tblue brings up 2 points that generally are the way it is.

• Big numbers look funny, but chrome is at "13.0.782.218 m" and I'd say 13 is a pretty big number. Google has the money and manpower to figure out what change makes which element change and at what frequency, but we're not google. Anyway I can also say that x.y.z looks funny when you realize there is nothing behind the segments.
• The drawback to major/minor is what do you consider major and minor? Personally I think the new readme popup thing is pretty major in that it takes us in a totally different direction than we've ever been in. OTOH if we ever do add app_nonces that too will be really major even though no one will actually notice. So even something as simple as "major/minor" is subjective. The number that follows 1 isn't really open to interpretation ya know?
• Nightly snapshot should always be the thing we call a release by the way.

So anyway I'll relate this back to the linked thread up there. To ME, we should release an official zip based purely on time and it should have a simple sequential number. Or maybe "X.0" because we know that nightly snapshot will get "X.lp-rev". version_compare() and almost any human could then understand what it all means even though most users won't care what lp-rev actually means.

With this as "the way" we could also start setting goals based on thirds of years. For example I know I want to get rid of the piss-poor shared-plugin-bits I started but never went after. Maybe if I knew we were going to make a release next month I might get off my lazy ass and start down that path. And perhaps Lee might think of doing the new floaty-box to at least one more thing, and perhaps Tblue might think of getting rid of at least one by-reference.

Anyway there you have it. Near as I can tell we currently have nothing for when and what, so I propose every 4 months and simple sequential numbering.

[Kimberly]

I agree that we need to start releasing versions but don't think it should be on a fixed every certain number of months. And a release shouldn't be looking at age to determine if one should upgrade but at version numbers. If we are going to do a check it should be comparing versions; "Your version is 3.2, the current release version is 4.3, click here to go see what has been changed.. or whatever". Change log, are we keeping a change log anywhere?

It probably is time to start considering pushing a new release out.

[Kimberly]

I think we should do point releases for bug fixes. Let's say we go with the every four months, if we do release every four months and just release version 4 and discovered that we have a few bugs that are easy to fix. We should go ahead and release an update, version 4.1 with the bug fixes. We should not wait four months and then say oops, 4 had some bugs we knew about but we sat on them until version 5. Especially so if the bugs are serious bugs.

[leeturner]

I think this all depends on how formal we want to be with our release process. If we release version 4 and there are bug in it that need fixing the formal way would be to branch at the release that went out, make the fixes, up the version to 4.1 and then do another release. The issue here is that these changes can't really be merged into trunk because trunk may have moved on since the bugs were found (they would have to be fixed in trunk as well of course) but at least users can be sure they have only what they had with version 4 plus the fixes that bump it up to 4.1.

Going down EdB's route, it gets a little simpler from our perspective - as he says, we are committed to not merging anything that will knowingly break things so if version 4 is released and bugs are found then someone branches as normal, fixes them, testing happens and then the changes are merged into trunk as normal. We then say if these bugs are a problem for you then all you need to do is go here and download 4.lp-rev and you will have the bugs fixed. However, there may be other changes included in 4.lp-rev that you didn't have in version 4, but hey, they still won't break anything

I am in two minds to be honest but I kind of like the whole OSS philosophy of release early and release often - whether that is on a 4 month cycle or not. Some people will upgrade, others won't bother as they don't want the disruption or the hassle. What we really need to be on top of is the ability to show people what has changed in each release so they can make that choice. EdB is already doing cool stuff with the changelog posts so this shouldn't be a problem. Ultimately more frequent releases will get more people using the features and more people testing them and hey, maybe an even more stable product. Better than waiting for ages before a new release is out to find it is full of bugs.

Not wanting to go too far OT here but another thing we need to decide is whether we are providing diff releases or not - as in these are the only files that have changed between version 3 and version 4 or whether we are just releasing full releases every time?

L

[EdB]

It seems "major.minor" is a more winning concept so I'm good with that. Whether major is by time or by decision and how we decide if a minor is worth an official release are up in the air, but major.minor seems to be a winning model.

I personally dig on Tblue's new lpv (which I like the sound and feel of better than bzr-anything and lp-rev), so I'm leaning on "major.minor.lpv". One core which we promise doesn't break is a really big thing for us. Enables the whole "this new bug/security issue is so important it has to be done now and will trigger a release" is the thing.

There could come a day where we want to change something so fundamental that we know keeping core intact won't be possible. So okay we dial in the last of what we were doing, have an officially planned major, and announce that snapshots won't happen as we do this new thing. The parallel would be when phpbb2 died and turned into phpbb3 for example.

On the diff release angle, I'm pretty sure the discussion around that was "yes we would because we can" and it will be beneficial to some folks. Providing a torrent for majors makes sense but providing a torrent for minors might be difficult due to someone has to manually handle it. Another angle of life on the server we have to figure out by the way. Nightly snapshot though only gets the auto-zip.

Off topic

Not totally OT, but we should put up a list of tasks and owners. Probably right next to the list of external thingies we use with what version we have. Things like "makes the diff for releases (Tblue), updates autodocs (EdB), builds torrents for majors and minors (?)" and so on and so on. I believe now many of those items would be credited to "nobody so if you're into this then raise your hand"

[EdB]

Another point that should trigger a minor release is "changes how plugins and/or templates are expected to be". We've done each of those recently with the hook name change and the template_type change.

So majors by something, and minors by "security, serious bugs, changes expected plugin coding, changes expected template coding".

These last two items by the way would make sense to bin until right before a major unless it was deemed critical to go forward. In other words CamelCasing those 2 hooks would have waited, but the template type would have happened to help enable app_nonces.

[Kimberly]

I was thinking that with our "ground zero" release on Jan. 1 that it would be nice to have a new release out by the winter solstice holiday.

[Tblue]

major.minor.lpv sounds good to me!

However, shouldn't changes to the plugin API/architecture trigger a major release? That way, as a plugin author, you can look at the version and tell if you need to update your plugin or not. So 1.2 -> 1.3 would mean "plugin will work" but 1.8 -> 2.0 means "plugin probably needs some changes".

[EdB]

I can enjoy that model probably more than time-based, although to be honest we should also set some sort of predictable trigger before a major happens anyway.

Major:

• Plugin API for sure, which we just had.
• What about database changes, which we just had one of?
• What about template structure, which we just had one of (but the templates with type=normal will still sort of mostly work)?
• Finally, what about some sort of "it happens now because of something
  • time? even 6 months though I prefer 4 months because there is no standard word for 4 months
  • number of branches since last major or minor?
  • number of minors on last major?

Minor:

• Serious bug fixes, though that is somewhat subjective.
• How about maybe any 3 bug fixes or something we deem serious?
• Security fixes, and again we'd have to decide on serious or not. Example "hey we have an unsanitized input" doesn't seem serious to me.

LPV:

• no-brainer eh?

Just to make clear: this is only a summation of what I think we're getting agreement on. I'd love to put it to anyone who cares enough to reply that they reply with adds or subtracts or concerns or ideas, and at some point actually wrap it up into a sticky about what our release program looks like.

One other thing we'll have to do is figure out what changes we will make to the contributors list. I mean, it can easily be part of any major or minor, but should probably not be just an lpv ya know? I say we leave Yabs on pretty much forever, but let's face it: there are many people linked on that file who simply don't contribute anymore. And we have new players contributing!

The thing is I think we should do v1.0.whatever since we meet the major criteria no matter how we actually define it.

[leeturner]

+1 for the major.minor.lpv

Actually EdB, I think you have pretty much summed it up pretty well there. I am not sure that a minor release always has to be something 'serious' though. If we have a release schedule of 4 months (which I think is pretty cool) and the only changes that we have made in that time are small additions or minor bug fixes then shouldn't we release with the same major version number but an increased minor number. The release schedule doesn't always need to be tied to a major version increase. If in the 4 months after that we hit one the criteria like a DB update then we release with an increased major number.

I like the fact that our development cycles are quite small and focused and I really dig on the whole release often philosophy - it shows we are an active project etc.

We should definitely do a 1.0 release next and as soon as possible.

L