[Libreoffice-qa] Lifecycle of builds?

Petr Mladek pmladek at suse.cz
Thu Apr 11 01:08:49 PDT 2013

Robinson Tryon píše v St 10. 04. 2013 v 11:29 -0400:
> On Wed, Apr 10, 2013 at 10:33 AM, Petr Mladek <pmladek at 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?

I think that only the single EOL date make sense. We do not provide
bugfix releases for bugfix releases. We provide bugfix releases for the
minor version X.Y.

> > 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.

Yes, I think that it can't work any other way. For example, if we
supported 3.6.7 for 6 months, we might need to release 3.6.8 to fix a
security problem. 3.6.8 would trigger another 6 months, ... We simply
need to cat it at some stage :-)

>  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

I have updated the table title at
https://wiki.documentfoundation.org/ReleasePlan to mention
"basic dates for the initial and bugfix releases". I wonder if this
might be enough.

> > 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

I would prefer to avoid these statements. Every release is different.
Some are pretty good from the .0 release. Some need more love. In
addition, it is individual. Some bugs might be critical for a certain
group of users and uninteresting for others.

In each case, we need to be in sync with the statement on the official
download page that is created by the marketing team.

> >
> > 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/

Thanks for the link.

> 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.

I am not sure how you mean this. Feel free to update the wiki.
Note that there is https://wiki.documentfoundation.org/TDFCertification
but the text need to be approved by BoD. You might need to discuss it
with them.

Best Regards,

More information about the Libreoffice-qa mailing list