Hello,
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? What happens for
bug discovered in distros ?
Especially if we have 3-4 X.Y release a year....
IMHO it is good to have a stable release of 3.3 after releasing 3.4 -
Here I fully agree,
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 ?
and that in what-ever X.Y.Z and X.(Y-1).W, only the latest Z and W are
supported? But this would implies to have at least within the X.Y path
an update mechanism, especially for Windows.
But this could lead to problems, since distro's have a more slowly pace
of release.
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 ?
This kind of scheme would limited (and clarify) the number of release
that are / could be cared of. (again, usefull with several X.Y a year)
So if you get a bug report, you know against which release you have to
test / it will be tested.
Just thinking loud... other wants to do it also? :-)
regards
Pierre-André
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.