On Tuesday October 25 2011 06:36:11 Anders Logg wrote: > On Tue, Oct 25, 2011 at 01:59:13PM +0100, Garth N. Wells wrote: > > On 25 October 2011 13:10, Anders Logg <l...@simula.no> 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 <l...@simula.no>: > > >> > 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.h...@gmail.com> wrote: > > >> >>>> On Monday October 24 2011 14:53:41 Garth N. Wells wrote: > > >> >>>>> On 24 October 2011 22:11, Anders Logg <l...@simula.no> 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 <gn...@cam.ac.uk> wrote: > > >> >>>>>>>>> On 24 October 2011 17:31, Garth N. Wells <gn...@cam.ac.uk> wrote: > > >> >>>>>>>>>> On 24 October 2011 16:58, Anders Logg <l...@simula.no> 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.
I am fine with either one too. That said I have the feeling that the release of 1.0 was a happening that was fuelled by the release of the book. When we do not have a book that burn our backs I have a feeling we are going to fallback into the "old" habbit of continuous developing with minor releases. If we are going to adopt a stable/unstable release we need a system of deadlines, which forces us to go in some sort of stabalizing mode. Most _big_ software projects have that, but I am not fully convinced we need it or are able to enforce such a scheme on FEniCS development. Johan > -- > 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" > > >> >>>> > > >> >>>> <m...@simula.no>: > > >> >>>>>>>>>>>>> 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/SeriesMilestonesRele > > >> >>>>>>>>>>>>> ases > > >> >>>>>>>>>>>>> > > >> >>>>>>>>>>>>> Yes/no? > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> _______________________________________________ > > >> >>>>>>>>>>>> Mailing list: https://launchpad.net/~dolfin > > >> >>>>>>>>>>>> Post to : dolfin@lists.launchpad.net > > >> >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~dolfin > > >> >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> _______________________________________________ > > >> >>>>>>>>>>> Mailing list: https://launchpad.net/~dolfin > > >> >>>>>>>>>>> Post to : dolfin@lists.launchpad.net > > >> >>>>>>>>>>> Unsubscribe : https://launchpad.net/~dolfin > > >> >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > > >> >>>>>>>> > > >> >>>>>>>> _______________________________________________ > > >> >>>>>>>> Mailing list: https://launchpad.net/~dolfin > > >> >>>>>>>> Post to : dolfin@lists.launchpad.net > > >> >>>>>>>> Unsubscribe : https://launchpad.net/~dolfin > > >> >>>>>>>> More help : https://help.launchpad.net/ListHelp > > >> >>>>> > > >> >>>>> _______________________________________________ > > >> >>>>> Mailing list: https://launchpad.net/~dolfin > > >> >>>>> Post to : dolfin@lists.launchpad.net > > >> >>>>> Unsubscribe : https://launchpad.net/~dolfin > > >> >>>>> More help : https://help.launchpad.net/ListHelp > > >> > > > >> > _______________________________________________ > > >> > Mailing list: https://launchpad.net/~dolfin > > >> > Post to : dolfin@lists.launchpad.net > > >> > Unsubscribe : https://launchpad.net/~dolfin > > >> > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~dolfin > > > Post to : dolfin@lists.launchpad.net > > > Unsubscribe : https://launchpad.net/~dolfin > > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
