revs and releases
First off this comes up from over here viewtopic.php?f=6&t=917
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.
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.
Tblue wrote: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.
- 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.
-
EdB
Dracone
- Posts: 2072
- Joined: Sun Nov 22, 2009 7:20 am
- Location: Maricopa Arizona