On Mon, Dec 1, 2008 at 6:26 PM, Michael Clark <[EMAIL PROTECTED]>wrote:

> Arthur Blake wrote:
> > On Mon, Dec 1, 2008 at 5:16 PM, Michael Clark
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >     Arthur Blake wrote:
> >     > Any comments on this, or shall I just check it in?
> >     > I was thinking about checking it in for 1.3 branch (creating one if
> >     > necessary) and the trunk both...
> >
> >     It looks good to me. I wouldn't bother with a branch for 1.3 -
> >     this is a
> >     bug fix, the code change is small and all the tests pass.
> >
> >
> > I think a branch *is* necessary since the trunk has changed quite a
> > lot since 1.3... otherwise how else would I do it?
> > I don't want to modify the 1.3 tag directly!
> > (would not we always do it this way after the main release has been
> > done, no matter how trivial the change??)
> >
>
> The branch is there already:
>
>  http://svn.jabsorb.org/svn/jabsorb/branches/1.3/
>
> We just need to backport the patch onto that branch and commit against
> the branch then make a tag for the release.
>
> The normal source code control practices is to make a branch before for
> a major release exactly so we have a place to position to place these
> minor maintenance bug fixes. We have so far been following these
> practices (the branch was created at 1.3 release time by William).
>
> After this minor patch releases is committed, we make a tag off of that
> branch. e.g.
>
> svn copy https://svn.jabsorb.org/svn/jabsorb/branches/1.3/ \
>  https://svn.jabsorb.org/svn/jabsorb/tags/1.3.1/
>
> e.g. branch for major releases, tags for minor releases.
>

Ah good.  I wasn't aware that was done.
I should have looked first ;)
Thanks.
_______________________________________________
Jabsorb-dev mailing list
[email protected]
http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev

Reply via email to