Skip to main content ↑ ↓
Topic: Beta to final and further development (Read 2519 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Beta to final and further development

Little question that popped in my mind few hours ago.

When 1.1 beta will be out, we will have a 6 month period in which there will be a master branch with the 1.0.x version, for maintenance, and, in the current setup, the development version will hold the 1.1 in stabilization (i.e. until it becomes final). Then, when 1.1 final will be released, master will hold 1.1 and development will be for 2.0.

This is nice, but it limits a bit what anyone can do, because for at least 6 months the development has to focus entirely on 1.1 and cannot even "think" to 2.0.

I was wondering: is it worth create another branch to separate the 1.1 stabilization phase from the "real" development?
This would mean that at any time, any one could decide to work on the code for 1.1 or 2.0 without having to hold back for a reason or another.
Of course there are few drawbacks, the most evident that when a change is made to master has to be merged in both 1.1 and 2.0 (and this may be a pain), and changes in 1.1 may have to be merged into 2.0. So a sort of double work.

Maybe wait until a couple of beta when the code looks stable enough? Or the current schema is good enough?
Bugs creator.
Features destroyer.
Template killer.

Re: Beta to final and further development

Reply #1 –

Versions should come from innovation. I think that says enough of what should be said.

Re: Beta to final and further development

Reply #2 –

You could also have an area54 type of thing, with branches of madness for a 2.0 playground. 

Like say I wanted to let folks play with a OO parse_bbc, I could create a branch under area54->parsebbc.  At the time we have a real 2.0 we could "in theory" pull those branches that we wanted in.  Looking that far out I don't think its worth trying to have a single 2.0 that you can put everything in, seems to difficult to maintain and you run a good chance of breaking each others playground.

Re: Beta to final and further development

Reply #3 –

Quote from: Joshua Dickerson – Versions should come from innovation. I think that says enough of what should be said.
Not really, not to me at least. :P (Unless you refer to the twisted versioning of a certain software, but it would be odd if you were to think I'm still bound to it that much.)
Define a version "number" comes from the need of distinguish packages released at different times, and since it was decided to follow http://semver.org/ , version numbers are defined based on APIs breakage.
In the release after 1.1 we aim at breaking most of the legacy APIs in order to change things, so a 2.0 is needed (and trust me when I say "breaking", I'm not Norv O:-) :P).

Quote from: Spuds – You could also have an area54 type of thing, with branches of madness for a 2.0 playground. 
Yup, that would be cool... a bit difficult to handle I feel, but probably doable. It would "just" require a new repo and keep them in synch.

Quote from: Spuds – Like say I wanted to let folks play with a OO parse_bbc, I could create a branch under area54->parsebbc.  At the time we have a real 2.0 we could "in theory" pull those branches that we wanted in.  Looking that far out I don't think its worth trying to have a single 2.0 that you can put everything in, seems to difficult to maintain and you run a good chance of breaking each others playground.
Well, the idea is not to have a 2.0 to throw everything in, but a 2.0 branch to start working on the 2.0 code. ;D
Bugs creator.
Features destroyer.
Template killer.