Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 24 Jun 2010 17:38:21 -0500

On Thursday 24 June 2010 16:59:41 Ralph Lange wrote:
> On Thu 24 Jun 2010 17:36:56 Andrew Johnson wrote:
> > The way I see it, 3.14.11+patches is our stable production release, the
> > 3.14 series is our near-term features release, and the other branches in
> > Bazaar demonstrate the directions we might go in.  Using a DVCS and
> > publishing lots of branches allows us to to avoid having to choose a
> > single direction for evolution before the development on each is
> > finished; I see that as much more Darwinian (and less risky) than the old
> > CVS approach of having a single branch for future evolution.
>
> After a discussion with Michael (also see his mail) it is becoming clear
> that we might have to reconsider our release policies and schedules. As
> you pointed out, the DVCS feature branches allow easier cherrypicking
> for the main direction; they would also make backporting single features
> to older releases easier.

So what do you suggest instead?  That was why I opened this topic.

> We should allow a faster integration of "heavy" new features (so that
> switching to cmake does not take 8 years), so maybe we need to be
> stepping up the minor number more frequent. (Maybe that is getting
> easier as we pass pi, but automated tests are crucial for any release
> model to work.)

I don't think I've said anything at all about how long we should go between 
releasing new major versions.  In Michael's case his cmake development is not 
going to be ready for 3.15, but if there's demand for it we could release 3.16 
soon after 3.15.1 if we wanted to.  The major number step gives users a clue 
about how much work they might have to put in to switch to that release, but 
they might skip the 3.15 series completely if a 3.16 series starts soon 
afterwards.  I'm hoping that we *don't* have such long major series in the 
future.

> In the end, the conflict is alway the same: We need to provide stable
> versions, and must not break production installations. But we also need
> people to be able to use new features, else those will never get mature
> enough to go into the stable version.

I guess we could consider there to be a difference between creating the 
release series and making the first actual release.  3.15 will be a branch and 
a release series, but we don't have to release 3.15.1 immediately. If we make 
one 3.15.0 would not be a production release, so there could be major changes 
between 3.15.0 and 3.15.1.  We could also produce 3.15.0.x releases which are 
not meant for production but contain stuff that we want to publish.  I'm not 
sure whether that's a good idea or not though.

Other ideas?

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System