dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Monday October 24 2011 14:21:14 Anders Logg wrote:
> On Mon, Oct 24, 2011 at 02:15:33PM -0700, Johan Hake wrote:
> > On Monday October 24 2011 14:11:40 Anders Logg wrote:
> > > On Mon, Oct 24, 2011 at 10:14:43AM -0700, Johan Hake wrote:
> > > > On Monday October 24 2011 09:45:40 Garth N. Wells wrote:
> > > > > On 24 October 2011 17:35, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> > > > > > On 24 October 2011 17:31, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> > > > > >> On 24 October 2011 16:58, Anders Logg <logg@xxxxxxxxx> wrote:
> > > > > >>> You mean follow Marie's suggestion but wait until we have
> > > > > >>> released 1.0-beta2?
> > > > > >> 
> > > > > >> I don't really see the need to wait.
> > > > > >> 
> > > > > >> I've registered a new series. The code is at
> > > > > >> 
> > > > > >>  https://code.launchpad.net/~dolfin-core/dolfin/dolfin-1.1
> > > > > >> 
> > > > > >> We can play around with how best to configure things. I had a
> > > > > >> look at a couple of projects on Launchpad to see how they do
> > > > > >> it.
> > > > > > 
> > > > > > Here are some examples:
> > > > > >   https://launchpad.net/unity
> > > > > >   https://launchpad.net/inkscape
> > > > > > 
> > > > > > I think that we should keep trunk for development, and each time
> > > > > > we get ready for a release series (1.0, 2.0, etc) create a new
> > > > > > series for it.
> > > > > 
> > > > > I made tried a few small changes on Launchpad - take a look at the
> > > > > overview page.
> > > > > 
> > > > > Note that the '1.0' branch is now
> > > > > 
> > > > >    lp:dolfin/1.0
> > > > > 
> > > > > lp:dolfin points automatically to the branch which is associated
> > > > > with the development series (which is now 1.1).
> > > > 
> > > > Looks good!
> > > > 
> > > > Not sure we should call the development branch 1.1 though. If we are
> > > > going to keep series for releases I think we can branch of a 1.1
> > > > series once the release is in preparation. This series will then be
> > > > for backporting of bug fixes.
> > > 
> > > Agree, the development branch should be called trunk. Then we branch
> > > off 1.1 when we get near release.
> > > 
> > > > We then need a policy for what goes into 1.X.Y releases.
> > > > 
> > > > I suggest that releases which brances from the development series
> > > > will get a bump in X and then Y is naturally set to 0. When there
> > > > are bug fixes in a 1.X series and we deside we should release a bug
> > > > fix for a stable sereies we bump Y for that series.
> > > 
> > > Yes. So we might have 1.0.1, 1.0.2, 1.0.3 etc for some time and at the
> > > same time have 1.1.0, 1.1.1 etc.
> > 
> > Exactly.
> > 
> > > Something to consider is whether we want to make frequent releases
> > > from the development version. That's how we usually do things and it's
> > > good to get testing. Then we could use the old Linux kernel versioning
> > > (which is now abandonded) and release 1.1.0, 1.1.1, 1.1.3 (odd X) as
> > > development releases, and when we think 1.1.5 or so is good enough, we
> > > branch off 1.2.0.
> > 
> > I think that is confusing and not nessesary for our project.
> 
> Wouldn't it otherwise mean that we need to bump X every time we do
> something interesting (and want to release it)?
> 
> I imagine that when it's time to make the next "stable" release (1.2
> with the above scheme), we will have added many new things. Those can
> then be tested by adventurous users of 1.1.1, 1.1.2, 1.1.3 etc.

I see that point, but wouldn't we have different interpretations of the Y for 
stable versus unstable series then? In a stable branch it is a release of a 
back ported bugfix and in the stable series it is a release of some features.

Also nan adventurous person could always use the nightly build packages or 
compile from source, which most adventurous persons do anyway.

We could start with development cycles with lower frequency of the X releases. 
A cool feature which we knew were stable could be backported, to a X.Y 
release.

Johan

> --
> Anders
> 
> > > (Hmm... maybe it should be called 1.1 as Garth says if we use this
> > > scheme.)
> > 
> > Yes, but I am not in favour of such a versioning scheme.
> > 
> > Johan
> > 
> > <meg@xxxxxxxxx>:
> > > > > >>>> > We seem to agree that it is time to split the dolfin-1.0 and
> > > > > >>>> > dolfin-dev development.
> > > > > >>>> > 
> > > > > >>>> > Rather than splitting off new development to a -dev branch,
> > > > > >>>> > I would suggest splitting off 1.0 at this point, cf. the
> > > > > >>>> > suggestions in "Creating series" on
> > > > > >>>> > 
> > > > > >>>> > https://help.launchpad.net/Projects/SeriesMilestonesReleases
> > > > > >>>> > 
> > > > > >>>> > Yes/no?
> > > > > >>>> 
> > > > > >>>> _______________________________________________
> > > > > >>>> Mailing list: https://launchpad.net/~dolfin
> > > > > >>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > > > >>>> Unsubscribe : https://launchpad.net/~dolfin
> > > > > >>>> More help   : https://help.launchpad.net/ListHelp
> > > > > >>> 
> > > > > >>> _______________________________________________
> > > > > >>> Mailing list: https://launchpad.net/~dolfin
> > > > > >>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > > > >>> Unsubscribe : https://launchpad.net/~dolfin
> > > > > >>> More help   : https://help.launchpad.net/ListHelp
> > > > > 
> > > > > _______________________________________________
> > > > > Mailing list: https://launchpad.net/~dolfin
> > > > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > > > Unsubscribe : https://launchpad.net/~dolfin
> > > > > More help   : https://help.launchpad.net/ListHelp