dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Oct 25, 2011 at 01:59:13PM +0100, Garth N. Wells wrote:
> On 25 October 2011 13:10, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Tue, Oct 25, 2011 at 10:01:45AM +0200, Martin Alnæs wrote:
> >>
> >>
> >> Martin
> >>
> >> Den 25. okt. 2011 kl. 08:11 skrev Anders Logg <logg@xxxxxxxxx>:
> >>
> >> > On Mon, Oct 24, 2011 at 03:45:26PM -0700, Johan Hake wrote:
> >> >> On Monday October 24 2011 15:37:08 Garth N. Wells wrote:
> >> >>> On 24 October 2011 23:29, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> >> >>>> On Monday October 24 2011 14:53:41 Garth N. Wells wrote:
> >> >>>>> On 24 October 2011 22:11, Anders Logg <logg@xxxxxxxxx> 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.
> >> >>>>>
> >> >>>>> Take a look now.
> >> >>>>
> >> >>>> Now it looks like there is one trunk and one 1.1 series. Is that correct?
> >> >>>
> >> >>> Yes. There is no 1.1 branch, but there is a 1.1 series and a milestone
> >> >>> so that we can target bugs and blueprints. We could also add a 1.2
> >> >>> series.
> >> >>>
> >> >>> Once most targeted 1.1 bugs and blueprints are closed, we can create a
> >> >>> branch from trunk to prepare for release.
> >> >>
> >> >> Ok, slowly getting there!
> >> >
> >> > I still don't understand this model. Where should development happen?
> >> > I expect it to happen in trunk, but then it won't go into 1.1.
> >> >
> >> > It now looks like we have to worry about three series: the stable 1.0
> >> > branch, the 1.1 branch and trunk. I prefer a simpler model with just
> >> > two branches: stable and development and then "branching" off the
> >> > development branch when we feel stable.
> >>
> >> Series != branch.
> >>
> >> There is no 1.1 branch yet, only the 1.1 series for targeting stuff.
> >> There are currently two branches, trunk and 1.0.x.
> >> Development always happens against trunk.
> >
> > That sounds good, but then I find the Launchpad graphics confusing:
> >
> > https://launchpad.net/dolfin/+series
> >
> > It still looks like three branches/series to me.
> >
> >> When entering testing phase before a release, trunk will be branched into 1.1.x just as it was now branched into 1.0.x. Bug fixes for 1.0.x will be pushed into the 1.0.x branch as well as trunk.
> >>
> >> I like the model. I do not see how this works out with the other projects yet.
> >
> > Does this mean that next time we feel like we've added a new important
> > feature that we want to release, that should be released as 1.1.0? And
> > then we need to go through the whole cycle of beta releases and
> > release candidates?
> >
> > I think we need a model where we can make "development releases" that
> > add new features without the big overhead of several months of testing
> > and stabilization. But once in a while (say once every year), we make
> > a new "stable" release that we maintain for a while.
> >
>
> That sounds a bit like the odd (testing)/even (stable) release numbering.

Yes, that's one way to solve it. The point is that I think we should
be able to make releases from the development branch without needing
to start a new stable branch every time we add a new feature.

> We could create milestones 1.1-pre0, 1.1-pre1, etc.

Yes, that could work too.

So instead of

  1.1.0, 1.1.1, 1.1.2, ...          development releases
  1.2.0-beta1, 1.2.0-beta2, ...     beta releases (approaching stable)
  1.2.0-rc1, 1.2.0-rc2, ...         release candidates (only bug fixes)
  1.2.0, 1.2.1, ...                 stable releases with bug fixes

we do

  1.1-pre0, 1.1-pre1, 1.1-pre2, ... development releases
  1.1.0-beta1, 1.1.0-beta2, ...     beta releases (approaching stable)
  1.1.0-rc1, 1.1.0-rc2, ...         release candidates (only bug fixes)
  1.1.0, 1.1.1, ...                 stable releases with bug fixes

?

Then it's only a naming issue. Either one is fine with me.

--
Anders


> Garth
>
>
> >
> >
> >> I was really not happy with the timing, these things should really not be done in a hurry without even the core developers knowing what is going on. I hope this means the beta3 is to be released ASAP, dual branches increases the workload on everyone.
> >>
> >> The buildbot still points to main which no longer exists. It should point to 1.0.x while we are stabilizing that.
> >>
> >> Martin
> >>
> >>
> >>
> >> >> Johan
> >> >>
> >> >>> Garth
> >> >>>
> >> >>>> Johan
> >> >>>>
> >> >>>>> Garth
> >> >>>>>
> >> >>>>>>> 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.
> >> >>>>>>
> >> >>>>>> 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.
> >> >>>>>>
> >> >>>>>> (Hmm... maybe it should be called 1.1 as Garth says if we use this
> >> >>>>>> scheme.)
> >> >>>>>>
> >> >>>>>>> Johan
> >> >>>>>>>
> >> >>>>>>>> Garth
> >> >>>>>>>>
> >> >>>>>>>>> After 1.0 we want 2.x.x or 1.1.x?
> >> >>>>>>>>>
> >> >>>>>>>>> Garth
> >> >>>>>>>>>
> >> >>>>>>>>>> Garth
> >> >>>>>>>>>>
> >> >>>>>>>>>>>> I suggest making the fork from the upcoming beta release, this
> >> >>>>>>>>>>>> gives a cleaner relation between branches.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Martin
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Den 24. okt. 2011 kl. 15:53 skrev "Marie E. Rognes"
> >> >>>>
> >> >>>> <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
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> 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
> >