Support forums : The Future

QP5 path: version numbers

The future of this project but not in a "I want a pony" sort of way. This is all about everything meta about Quam Plures. The general direction, the support tools, stuff like that.

Moderator: Dracones

QP5 path: version numbers

Postby EdB » Sat Feb 16, 2013 7:26 pm

gonna do a few of these "QP5 path: foo" topics so's we can have some dialog about some of the things I chose for QP5 before they get in here and people start wondering what's the deal with that ...

So version numbers. What I started doing was basically making each "branch" have a new version number. With multiple authors that'll be kinda hard to work out, but not impossible. For example QP5 was just about to release v1.44.67 where 1 is the overall version, .44 meant 4 kinda noticeable with 4 more hardly visible changes, and .67 was the dbase number.

I was also putting the version number in the changed files just because I was, but that level of detail I am pulling out of the branches I'm starting to make.

Anyway for a little while there's gonna be lots of big branches going into merge so I'm not going to continue changing the version number, but we really should come up with a plan for this. We have the nightly build happening, so in a way we have a "package" being released each time we do a merge. What we COULD do if we wanted is maybe something like this: when we know something is gonna be merged we hang for a bit ... even if the 10 days has elapsed IF there is something else coming soon. On actual merge day the person who will do all the merges makes one more merge at the end to update the version info and release date. We won't have the version number inside each changed file, but our nightly build will capture the new release number :)

For example I just did 5 or 6 merges to core. The nightly build won't capture the steps between, but will show all these merges as "different" from the last nightly build.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: QP5 path: version numbers

Postby leeturner » Sat Feb 16, 2013 10:35 pm

EdB wrote: On actual merge day the person who will do all the merges makes one more merge at the end to update the version info and release date. We won't have the version number inside each changed file, but our nightly build will capture the new release number :)


I like that idea
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: QP5 path: version numbers

Postby Kimberly » Wed Feb 20, 2013 6:32 am

I am flexible. I don't care for the mozilla; release a new release every x weeks. Chrome is up to version 24, Firefox 16 or 18 or whatever. Soon they will be at version 2045. There is nothing wrong with being at version 4.5 six months from the release.

Question, do we fix bugs and release, or do we release on features only? Example, Boonex has released Dolphin 7.1 Final; it was full of bugs, they are fixing them but waiting to release 7.1.1 that will contain the bug fixes. Or do we fix bugs, roll into the release, and keep the version number; or fix bugs but hold them until we do a new release?
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: QP5 path: version numbers

Postby EdB » Wed Feb 20, 2013 7:32 am

Here's what I think. We don't say "a release every X days", nor do we say we will wait to make a release. When we have branches we're changing the product, so that more than anything else drives releases. With a 10-day window to engage in the improvement process we're sort of slowing down releases, but we can also just say "this bug fix really really needs to be done NOW so lets get it done and out there" - in other words bypassing the idea of 10 days ... or maybe accepting that we don't need the delay if we're all on board with the specific bug fix.

Version numbers are a different animal. I just now got FF19 upgrade. Personally I don't care what they call it I just don't wanna lose my addons :) But for us we can put some meaning into it. The first digit is kinda like generations. Or more accurately it'll be more work than normal to upgrade. That sounds like a nice approximation of a plan :) The next pair (or 3?) numbers would be steps along a path of unknown length. Basically just to differentiate between (effectively) branches getting merged into core. The only meaning embedded in the numbers would be simple: 24 is newer than 12 but older than 36 :) The last digits is the easiest part: database changes. Currently core has only 4 changes from the very first release, so it is a 4. The monster branch takes that to 67 because, literally, there are 63 more separate unique database changes involved.

For a good example of how this will work, after "monster" works and gets cored it'll be files version 1.00 and database version 67, or an overall version of 1.00.67. The 1 means expect some work going from any 0.xx.xx to it. In this case template and possibly plugin editing. The 00 says we're at the beginning of 1, and the 67 is a simple measurable fact.

Adding mobile detection might make us call it 1.10.75 or maybe just 1.01.75 if we're detecting but not actually using? To be honest the middle digits don't matter much - as long as they tell someone that it is a newer set of files than 1.00 was :)

So no real timeline involved unless we feel the need to make it happen NOW, and a scheme that sort of has info in it, but not like a committee has to have a meeting to make the right number choice. Just an indication of reality is all.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: QP5 path: version numbers

Postby leeturner » Wed Feb 20, 2013 7:42 am

I think releases need to happen more frequently than they did before (ie never) but we can be flexible about when they happen. We have the nightly builds for people who want to live on the edge and I think specific bug fix releases (security especially) are a good idea.

If we can streamline the process of making a release it doesn't have to be such a big deal. This includes all the changes in a given release etc.
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: QP5 path: version numbers

Postby Kimberly » Wed Feb 20, 2013 5:53 pm

OK, I understand. Do we want to consider that this is a first release at this point and reset the database number as well are leave that as is?

What I am hoping is that once we are at a stage where you say, this is it; I will download the package, install it and do some real world testing, actually setting up a site and using it. Then if we think it is at a stage where we can release it as a version; I want to do that. It has been some time since we released QPv0.

The social buttons we have listed; Does anyone have those accounts and can access them? I am thinking Press Release :D
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: QP5 path: version numbers

Postby EdB » Wed Feb 20, 2013 6:09 pm

The dbase number will force anyone who has QP (either 0.0.0 or any nightly snapshot) to do the upgrade thing, so IMHO it needs to stay where it is ... currently 67 in monster.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: QP5 path: version numbers

Postby leeturner » Wed Feb 20, 2013 6:16 pm

EdB wrote:The dbase number will force anyone who has QP (either 0.0.0 or any nightly snapshot) to do the upgrade thing, so IMHO it needs to stay where it is ... currently 67 in monster.


Agreed
leeturner
Dracone
User avatar
 
Posts: 730
Joined: Fri Dec 11, 2009 11:55 am
Location: Brighton, UK

Re: QP5 path: version numbers

Postby EdB » Wed Feb 20, 2013 6:59 pm

The branch and zip are completely ready for testing :)

Perhaps we should do some sort of official release thing? I was thinking the nightly snapshot could be a release, but maybe we stay with that as a nightly snapshot and still have an official release every now and again? That gets us into the whole press release angle (which is good) but gets us back to not knowing when (which is bad). Quarterly? Or every 4 months - which has no official term by the way? or X number of branches committed?

It's complicated and personally I don't think it takes complication. Personally if we change the files or database - to me - that's a new version. BUT maybe not ...
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: QP5 path: version numbers

Postby EdB » Wed Feb 20, 2013 7:18 pm

I just had this really crazy idea: instead of killing QP5, which I figured I'd do on my workweb once the monster branch was done in core, why not keep it alive as another project on launchpad? We can keep all the plugins and templates in it maybe, but more importantly use it as a testbed for branchwork over here.

Basically give the same teams permissions to play there, and that becomes a playground for this. Those into "bleeding edge changes" can grab QP5, once stuff feels really stable there we bring it here for a release cycle.

By the way, the diffs are a little more complicated than they should be which is fixable. There are some hard references to Quam Plures here that are QP5 there, so those need to change to using $app_name. Other than that, there is one file and two images that are different.

Just a thought ...
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Next

Return to The Future

Who is online

Users browsing this forum: No registered users and 1 guest

cron