Jump to:

17452 Posts in 4473 Topics by 1971 members

Archive

SilverStripe Forums » Archive » Release procedures

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

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

Page: 1 2
Go to End
Author Topic: 3631 Views
  • Sam
    Avatar
    Administrator
    679 Posts

    Release procedures Link to this post

    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.

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: Release procedures Link to this post

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: Release procedures Link to this post

    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?

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Release procedures Link to this post

    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").

  • Hayden
    Avatar
    Core Development Team
    19 Posts

    Re: Release procedures Link to this post

    2.0.0 has been created as a tag, so we do have that known point to work with.

  • Anonymous user
    Avatar
    22 Posts

    Re: Release procedures Link to this post

    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?

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: Release procedures Link to this post

    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.

  • Anonymous user
    Avatar
    22 Posts

    Re: Release procedures Link to this post

    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.

    3631 Views
Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.