Re: [Bashburn-info] 3.0 Beta 1

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 18:28:45 you wrote:
> On Tue, 07 Oct 2008 15:44:31 +0200
>
> Markus Kollmar <mar...@on...> wrote:
> > Anders Lindén wrote:
> > > On Tuesday 07 October 2008 15:11:50 you wrote:
> > >> Anders, we have a small problem with Beta 1!
> > >>
> > >> I have done yesterday some changes in the trunk (also the
> > >
> > > mentioned
> > >
> > >> swedish language updating).
> > >> Now I saw you have not moved all files for the release 3.0 from
> > >
> > > 'trunk'
> > >
> > >> to 'release' shortly before you created the release-package.
> > >
> > > Ouch! Which files are we talking about? I could add the missing
> > > files and do a quick re-release.
> >
> > Anders, I think that is not the best idea (it are some files like
> > "BashBurn.sh" and lang. files - and maybe I think Nick and maybe
> > others also did improvements since then).
> > So in such cases we should always take the whole thing to avoid
> > dependency-problems - if we can be shure nothing is broken - 
and i
> > think in this short time the trunk is relatively usable.
> >
> > >> I should had tell you this - so you thought that there was no 
major
> > >> changes in the trunk since you created the release branch.
> > >> In my humble opinion I think it would be good if we use 
following
> > >> process to make a release and to avoid such things in future:
> > >>
> > >>
> > >> 1. Like you did - tell others per mailing list shortly before
> > >> release whether it is ok to create a release for the main
> > >> developers, and tell the short time period in which the 
creation
> > >> is planned.
> > >>
> > >> 2. Then lock the trunk branch (via "svn lock") and move ALL 
files
> > >
> > > from
> > >
> > >> trunk to release.
> > >>
> > >> 3. Create package from release tree.
> > >>
> > >> 4. Unlock trunk branch.
> > >>
> > >>
> > >> Is this a way?
> > >
> > > Sounds like a good idea to me.
>
> Also what I meant was all changes go to TRUNK.  Then and if tested 
etc.
> export that particular fix to RELEASE.
>
> As it is, I think the whole trunk can be cp'ed to RELEASE (i.e. trash
> RELEASE tree and start from this working version).
>
> Then all new development starts again on TRUNK.
>
> Nick

I don't think we really have to nuke the release tree for each release, 
just create a new sub directory under it. One mistake we might have 
done with this release is that we just called it 3.0, even for beta 
releases. I think in the future we should create releases/3.1-beta1, 
beta2 and so on and then simply create release packages from those 
directories. 

Nothing new from trunk will go into those. What should be allowed to 
change in release is just release specific things like editing the 
installation script (Like I did with 3.0-beta1) or changing the version 
number.

What I think we should do now is to rename releases/3.0 to 
releases/3.0-beta1. After we get some bug reports and/or fix some 
things ourselves in trunk and we feel things are done, I'll create a 
releases/3.0-final (Or beta2 should we think it's necessary) from trunk 
and leave the beta1 directory alone. 

-- 
Anders Lindén
http://bashburn.dose.se