dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Oct 24, 2011 at 02:38:00PM -0700, Johan Hake wrote:
> 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.

Yes.

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

Sure.

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

I'm not sure. I don't necessarily advocate the Linux kernel scheme
with even and odd numbers, but I think we should strive to make
releases often, even from the development branch.

--
Anders