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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

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   4402 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?