17452 Posts in 4473 Topics by 1971 members
Page: 1 2
|Go to End||Next >|
5 February 2007 at 11:53am
With the first stable release of SilverStripe now out, we're going to need to change our release procedures slightly.
* 2.0.0 will be tagged in the system
* 2.0 will be merged back into the trunk.
* No more changes should be committed the 2.0 branch. If this is going to cause complications, we should discuss how to resolve them.
* Big development on new features will happen on the trunk, which will be branched to 2.1 when the time is right.
5 February 2007 at 1:12pm
These have been documented at: http://trac.silverstripe.com/wiki/release-procedures.
5 February 2007 at 5:50pm
The 2.0 branch of jsparty, cms and sapphire should only have critical bug-fixes committed to it. We need to work out a way of enforcing this - perhaps we should lock off commit access to all but 1 or 2 developers? Or perhaps we can just get everyone to re-check-out these modules in some sort of read-only mode?
What approach shall we take and how can it be implemented?
5 February 2007 at 6:26pm
hm, batch-setting of svn:externals to trunk and forcing developers to svn-update all their environments? if a specific project still needs to be on 2.0 stable, this could be reverted by the assigned developer.
additionally, you can lock files in a svn-repository:
seems like the "lock-owner" would then need to unlock the file before any commit can happen (or any user with "unlock --force").
Core Development Team
7 February 2007 at 8:36am
2.0.0 has been created as a tag, so we do have that known point to work with.
7 February 2007 at 9:07am Last edited: 7 February 2007 9:31am
Conceptually, the 2.0 branch shouldn't exist after it's merged back into trunk. That's the point -- branches only live as long as they need to. For example, if there was an "Clowns and Puppies" port of SilverStripe, that branch may live a very long time (because everyone likes clowns and puppies ;-) ). But some branches, like a "2.0 branch" which is always intended to be merged back into the trunk, should die a graceful death.
This will clean things up in a real way and make life simpler.
One effect: after the merge of 2.0 onto trunk, we'll need to modify the scripts and definitions of projects in subversion to point to trunk.
Radically new, unstable development would go on a branch, like 2.1 or 2.1-kittens, until 2.1-kiittens becomes stable, gets merged onto trunk, and the cycle repeats.
Here's some good thinking on the topic. If we adopted something similar, I think that would be good:
7 February 2007 at 9:32am
You're assuming that the trunk is the most stable code - the production code. I was assuming that the trunk was the development code, and 1 or more branches contain the production code.
Stable branches seems to be more popular, and the advantages of them are as follows:
* You can have more than 1 stable branch.
* You don't have this situation where you need to merge development code back into the trunk, which for a brief moment then becomes unstable. What if someone needed to publish before you had done all your testing?
An alternative, I suppose, would be to get away from the whole trunk/branches/tags structure and change it to something like:
In other words, ditch "trunk", split branches into "stable" and "development" and rename "tags" to "releases".
In order to 'stabilise a branch' you would move it from development to stable. And any new version would start as a development branch.
7 February 2007 at 11:57am
A question: why would you need more than 1 stable branch? Seems like that could cause more confusion than it's worth.
Using the trunk for work in progress is more of the typical way of working, especially when you're developing a site. So that seems fine to me.
Renaming "tags" to "releases" might be a bit clearer, true, but as long as people still treat it (enforced?) as read-only time-based snapshots, I don't see much of a difference either way.
Hmmm. I'm still not seeing a big reason to split trunk into "stable" and development". I think creating a specific "stable" branch as needed would be just fine. The basic model (trunk, tags, branches) still seems to be sufficient and simpler to me.
Page: 1 2
|Go to Top||Next >|