On Wed, Apr 10, 2013 at 10:33 AM, Petr Mladek <pmla...@suse.cz> wrote: > I see that you both use a bit different logic, so we need to decide how > we count the 6 and 9 months. I understand it the following way: > > + the release is defined by the minor version release, e.g. 3.6 > or 4.0 > + regular and extra bugfix releases are provided during the > life time > + the life starts with the .0 release > + the life ends when we are not willing to provide any new > bugfix release
So would we provide an EOL date for each point release in a series, or just a single EOL date for all of our 3.6.x released builds? Granularity is nice, but one EOL for the entire release series might be easier to manage. I'd often thought of each 3.5.x build as a separate release, but as you describe it, it's mostly just a maintenance schedule. > I think that it would be fair to make it live at least 4 weeks after the > last scheduled bugfix release. By other words, we should provide extra > bugfix release if we add serious regression into the last bugfix > release. 4 weeks of support for a regular build seems pretty short, but when you describe it as a "bugfix release," it makes a lot more sense in my mind. Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? Maybe in the tables of releases: 3.6.0 ... 3.6.6 bugfix 3.6.7 bugfix Is there a better/shorter label we could apply there? > If we do it this way, the numbers would look like: > > version start end length > > + 3.6 Aug 8, 2012 Aug 14, 2013 12 months > + 4.0 Feb 6, 2013 Nov 20, 2013 9 months > + 4.1 Jul 24, 2013 May 28, 2013 9 months > > It is basically what Michael mentioned because the .0 release is for > early adopters. The release is stable around .3 bugfix relase which is 3 > months after the .0 release. Ah, okay, so perhaps a new column in the table: 3.6.0 - early adopters 3.6.1 - (or maybe 'unstable'? marketing would hate that..) 3.6.2 - (Better: leave it empty until we can mark it 'stable' :-) 3.6.3 - stable ... 3.6.6 - bugfix 3.6.7 - bugfix Then if we had to add an extra bugfix, we could do something like 3.6.8 - special bugfix Unlike the rest of the information in the table, the labels in this column could be added at each new release, especially as we don't know at the outset which point release we'll feel confident to mark as 'stable'. > > I wonder if there is a list of certified developers somewhere. I have > found only the description at > https://wiki.documentfoundation.org/TDFCertification https://www.documentfoundation.org/certification/developers/ I would suggest that you link to some internal page on the wiki (say TDF/certification), as it's likely that other pages will want to mention the certification program or the currently-certified developers. --R _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/