Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Release procedures


Go to End
Reply


9 Posts   3789 Views

Avatar
Sam

Administrator, 685 Posts

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.

Avatar
Sam

Administrator, 685 Posts

5 February 2007 at 1:12pm

These have been documented at: http://trac.silverstripe.com/wiki/release-procedures.

Avatar
Sam

Administrator, 685 Posts

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?

Avatar
Ingo

Forum Moderator, 801 Posts

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:
http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html
http://svnbook.red-bean.com/en/1.2/svn.advanced.locking.html
seems like the "lock-owner" would then need to unlock the file before any commit can happen (or any user with "unlock --force").

Avatar
Hayden

Core Development Team, 19 Posts

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.

Avatar
Anonymous user

22 Posts

7 February 2007 at 9:07am

Edited: 07/02/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:

http://ariejan.net/2006/11/24/svn-how-to-structure-your-repository/

Thoughts?

Avatar
Sam

Administrator, 685 Posts

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:

stable/2.0
development/2.1
releases/2.0.0

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.

Avatar
Anonymous user

22 Posts

7 February 2007 at 11:57am

Good points.

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.

Go to Top