Re: [Libreoffice] release plan : inconsistency between 3.3.3 and 3.4

Hi Pierre,

On Tue, 2011-04-19 at 21:45 +0200, Pierre-André Jacquod wrote:
> jumping late into the subject, but....

        :-)

> On 04/11/2011 12:25 PM, Michael Meeks wrote:
> >     The plan is (of course), to keep releasing 3.3.x releases as long as
> > people are interested in creating them I suppose[1] - we should come up
..
> May I disagree ?? This is not a very predictable use for all involved: 
> users, distros, etc... When to jump to next version ?

        When a user should jump to the next version is never clear - and it
depends on your risk aversion, and interest in features. We can't make a
single decision that is right for all users here. Our business users
want to change very infrequently, and have very long support timelines:
vendors will end up supporting some releases in enterprise products for
many years ;-)

        Other users (and developers) want quick releases, with the latest
improvements and fixes, counting on the benefit of these to outweigh any
new bugs they might hit. They also want to report bugs that are useful
to improve the cutting edge.

>  What happens for bug discovered in distros ?

        They merge the bug fix to all the branches it applies to, and that they
care about. I expect people to decreasingly care about very old
releases. If people do care, they can back-port and test fixes - I don't
see why we should stop that.

> Especially if we have 3-4 X.Y release a year....

        Well - we have a 6 month cadence for major 3.X releases - so 2 releases
per year, and something like a monthly cadence for 3.X.Y releases - so
sure, we can end up with ~10 releases a year or so - of which, only the
latest versions of each will be interesting for developers.

> Could it be not possible to have some rules, like the release of version 
> X.Y.0 means end of support for X.(Y-2) version. En in case of X.0.0 
> version, only the latest (X-1).Y.Z version is supported ?

        Sure - we could do that; but if vendors have to support those versions
anyway (as they will have to), and they actually care - I don't see any
reason why we should forbid them from putting their fixes into the git
branch and them doing releases.

        Practically, I can't see enthusiastic build resources being applied to
3.3.x release for many more iterations once 3.4 is out - but if others
want to step in - why not ?

> So what about picking long term support, e.g. 3.5 is long term support, 
> means 2 years, what ever happens for the number of releases ?

        Not a bad idea; but picking that version is difficult; and ultimately
I've not seen another up-stream Free Software project that does this. If
customers want endless support - it is a tedious job, and they should
pay someone, anyone to provide that for them.

> So if you get a bug report, you know against which release you have to 
> test / it will be tested.

        Ultimately, I think we are only really interested in bug reports
against the latest stable, and development versions, otherwise we'll end
up with a clogged up bugzilla :-) let see ...

        ATB,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot