Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 7 Oct 2008 18:45:38 +0200
Anders Lindén <and...@gm...> wrote:

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

OK, but what I meant was that TRUCK (as it is) is tested upto NOW.  So
I thought that would become the beta1/2 or whatever.

But anyway, we are there :-)

Nick
-- 
Free Software Foundation Associate Member 5508