dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #24846
Re: Branching off 1.0 or 1.1
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.
We could create milestones 1.1-pre0, 1.1-pre1, etc.
Garth
> --
> Anders
>
>
>> 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
>
Follow ups
References