Re: howto make a reliable release-0.22

Hi,

In my company we have used Subversion for many years now. We used to
develop using the trunk but this causes huge issues when trying to get a
release out due to 'development' being somewhat continuous. It also
develops odd dependencies.

One year ago we moved to trunk being sacrosant. With no dev commits. We
have each issue in Scarab worked on a separate branch (features/<id>)
(Ive developed a lot more advanced hooks for subversion to help support
this).

When we release we produce a release candidate (release/<num>-rc<num>)
this is branched off the main.
Those 'features' which are to be released are merged in. The release is
tested. Should conflicts occur these are resolved in the release branch.
Should fixes be needed they occur back on the original branch. We then
make the next release-candiate by branching from the previous and
merging the new changes. When a final release is OKd. We create a new
branch from the last release-candidate and merge in any final fixes
which will not affect the release status.  At this point a release has
occured and all the changes made to the release branches for all the
rc's and the final are then merged in order into the trunk.

All features branch from the trunk unless specifically dependent on code
on a specific release.

This way of working has been a godsend. We can now work on features for
months yet never *have* to release them - in fact this occured recently
where we were making changes to support a new supplier's protocol but
due to problems with the new protocol (and the supplier who we are now
ditching) we did not release the code - this is not a problem but since
development on the protocol update branch started we have made 3 s/w
releases since then - continuing to use the old protocol. **If we had
done all this work on the main trunk a release would have been
exceedingly difficult to ever produce as we would have had to unpick the
'not to be released' development work.**

Branches in subversion are cheap so the cost of branching is negligible.
I therefore recommend (1) as an approach whole-heartedly its already
paying us dividends. Its a little more effort. But it saves massively in
the release cycle.

TTFN
Barry

hussayn wrote:
> It sounds like all of us would like to see the 50 non closed 0.22-related
> issues fixed,
> before we create release-0.22. Only then we want to get back to work on
> trunk.
>
> But lets face it: We do have 200 open issues at the moment in total.
> But if you look on the other side of the coin, i think some of us are
> running trunk as
> productive system. So it can't be soo bad, no ? I myself am running trunk
> since
> 7 months on at least 4 Scarab instances and i am quite happy with it.
>
>
> IUnstead of freezeing trunk, we still do have alternative ways to go.
> I see 3 options:
>
> 1.) freeze trunk, all "new" features go to branches.
>
> pros: all efforts go into the release.
>         next release could be stabilized faster.
>
> cons: continuous work is full stopped.
>         never ending discussions about what is a fix, what is a feature
>         all new features/enhancements go to branches,
>         so each developer is isolated from the others.
>         branches must be maintained separately.
>         espcially take must be taken to later be able to merge back to
> trunk.
>
>
> 2.) branch to a release branch, all release fixes are ported back into the
> trunk
>
> pros: We do have a definitive cut, so new features in trunk don't disturb
> release fixing.
>         work on trunk can continue
>
> cons: less resources for the release fixing.
>         more effort on backporting release fixes.
>         danger to loose fixes, so that a bug fixed in release x might
> reappear in relase x+1
>
>
> 3.) Just continue as we do right now. Occasionaly we hear somebody moaning
> about Scarab is
>     dead, no release since 2 years. Yes you are all right. But i guess, we
> do have a capacity
>     problem...
>
> pros: allow developers maximum efficiency
>         keep testing as efficient as possible (no branches to be tested
> separately)
>         allow for quick turn arounds, since every commit is equivalent to a
> microrelease.
>
> cons: no defined release in the classical sense
>
> summary: To me it looks like everybody wants a new release, but nobody wants
> to, or has the
> time to actually do the release work. I don't exclude myself. I cna
> understand that.
> I have done release work in the past and it is a frustrating job which needs
> a huge amount of
> effort especially because many bugs are almost not reproducible, or need
> significant care
> taking to setup an environment so that such a bug can be efficiently tracked
> down. from my own
> experience i remember, that we started a release branch for the last
> revision, and it took us
> several weeks to get the release actually done. I simply do not find the
> time to get into
> another release cutting session. And i am afraid, there is no big pressure
> on anyone of us to
> actually do such a move ...
>
> So here is my personal conclusion: I personally opt for keeping Scarab
> development as it is
> for the moment. My own tasklist involves quite a few usability enhancements,
> which might very
> well make many open issues silently become obsolete. I very strongly opt for
> making a
> release-branch and keep trunk what it is, the development branch. And
> freezing the development
> branch doesn't sound too good to me ;-(
>
>
> And here is my proposal:
> Create the 0.22 release branch and fix branch-related issues there as needed
> and as time can
> be found. I will help too and put my hands on release-fixing issues, but
> with a low priority.
> As soon as all 0.22 related bugs are fixed in the release branch (and
> hopefully also ported to
> the trunk) Scarab is ready for release 0.22. Doing so, might help to make us
> feel much more
> comfortable:
>
> - we have established a well defined release-branch, containing everything
> relevant for  the release
> - we can stabilise in a very controlled way. No move from trunk to release.
> - trunk is free for contineous development.
>
> So what do you think ?
>
>   

-- 
Sincerely Yours

Copyright Witness Net Support
[email protected]

www.copyrightwitness.com
Registration centre for copyright works.

This e-mail and any attachments are confidential and intended for the addressee only.
The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=1013505

To unsubscribe from this discussion, e-mail: [[email protected]].