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, Ed, biapar, Willr, Ingo

Release procedures

Go to End

7 Posts   4390 Views


Administrator, 690 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.


Administrator, 690 Posts

5 February 2007 at 1:12pm


Administrator, 690 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?


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:
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, 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.


Administrator, 690 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:


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.


Administrator, 690 Posts

7 February 2007 at 3:26pm

Sometimes a site won't want to upgrade to the latest stable release of SilverStripe: despite our best efforts, a later version might break the particular site in question.

For this reason, I think we should keep older versions listed in branches until no-one is using that release any longer.

There were a couple of advantages to using stable / development, but they were more "nice to have"s than anything to justify the hassle of a switch.
Perhaps, once a release goes stable, people could request tags/2.0.0 from subversion instead of branches/2.0. This would mean we could make tags/2.0.0 read-only, and not get any accidental commits.

If people wanted to fix a critical bug in 2.0, they could explicitly request branches/2.0 from subversion.

Can we set up tags/* to be read-only access?