Re: [Membership] Plone Version Support Policy: Call for Input

[vedaw]

I'm not sure that I'm the best person to speak here, but I don't even
remember exactly when 3.0 came out, and drawing a line of a year feels
awfully random to me. Version-based support sounds better to me, for
security fixes only.

I think we need to have a methodology for determining if it's time to let a
release fade into the mists:

1) Is documentation for the current version up to date?

2) Has plone.org managed to move to the new version?

3) Has the volume of questions started leaning toward the newest version of
Plone (80% at least)?

4) Do we have the volunteer power to do minor security fixes to older
versions?

5) How long will it be before the next major release? (1 or 2 years is an
awfully long time to wait, and what's the harm in doing small security fixes
to an older version in that time frame?)

As far as 2.5 goes, it feels like we don't have clear metrics for making a
clear decision. 4.0 feels very far away, and the fixes that have been
applied to 2.5 haven't been onerous, as far as I can tell. I'd personally
like to see 2.5 supported at least into the middle of next year (when the
doc team can hopefully get into sync with the 3.0 folks), but that's just my
two cents.

- Veda


On 12/19/08 2:15 PM, "Steve McMahon" <[hidden email]> wrote:

> Hello Plone Foundation Members,
>
> The Plone Foundation Board would like to work on developing a good
> policy for support of Plone versions prior to the current. It's become
> clear that there are some differing community expectations on this,
> and that there's not a clear decision-making process.
>
> Two of the common beliefs on support are: 1) that we'll support two
> major versions at a time, or 2) that we'll support a major version for
> a year after release of a new current version. There are also
> different definitions of "support"; the most common is probably that
> security fixes will be backported when technically feasible and that
> documentation will be maintained.
>
> Our move to a longer gestation period for larger version changes is
> probably the source of the confusion. It's probably not reasonable to
> expect support for a prior release to always continue for two-or-three
> years. On the other hand, when version changes are such a big
> transition, a year may be too short.
>
> The board tries to keep out of decision-making about development, but
> the foundation funds release managers and generally manages
> non-volunteer resources. This policy will also impact marketing and
> how Plone is perceived, and can be seen as bigger than individual
> development decisions. The board will therefore take the
> responsibility of defining this policy and making it official, but
> only in close consultation with the Plone community.
>
> We'd particularly like to hear from the Plone Foundation membership,
> and would welcome a membership-list discussion or mail to the board
> <[hidden email]>. What should our support policy for
> non-current versions be? What does "support" mean for non-current
> versions. Should a policy be time-based or version-based?

------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Wichert Akkerman]

Previously Veda Williams wrote:

> I'm not sure that I'm the best person to speak here, but I don't even
> remember exactly when 3.0 came out, and drawing a line of a year feels
> awfully random to me. Version-based support sounds better to me, for
> security fixes only.
>
> I think we need to have a methodology for determining if it's time to let a
> release fade into the mists:
>
> 1) Is documentation for the current version up to date?
>
> 2) Has plone.org managed to move to the new version?
>
> 3) Has the volume of questions started leaning toward the newest version of
> Plone (80% at least)?
>
> 4) Do we have the volunteer power to do minor security fixes to older
> versions?
>
> 5) How long will it be before the next major release? (1 or 2 years is an
> awfully long time to wait, and what's the harm in doing small security fixes
> to an older version in that time frame?)

The problem is that none of these are predictable or measurable. And
predictability is very important: if someone is going to spend a lot of
money on a Plone site he will only do so if they know in advance how
long they can count on support.

Wichert.

--
Wichert Akkerman <[hidden email]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Dylan Jay-4]

Is the plan to maintain a copy of each manual for each Plone release on
Plone.org, as well as the current one?

Dylan Jay
Technical Solutions Manager, PretaWeb.com
---
M:[phone] ~ MSN:[hidden email] ~ Y!+Skype:dylan_jay ~ ICQ:520341

> -----Original Message-----
> From: Veda Williams [mailto:[hidden email]]
> Sent: Saturday, 20 December 2008 10:34 AM
> To: Steve McMahon; Plone Foundation Membership
> Cc: [hidden email]; PF Board
> Subject: Re: [Plone-docs] [Membership] Plone Version Support Policy:
> Callfor Input
>
> I'm not sure that I'm the best person to speak here, but I don't even
> remember exactly when 3.0 came out, and drawing a line of a year feels
> awfully random to me. Version-based support sounds better to me, for
> security fixes only.
>
> I think we need to have a methodology for determining if it's time to let
> a
> release fade into the mists:
>
> 1) Is documentation for the current version up to date?
>
> 2) Has plone.org managed to move to the new version?
>
> 3) Has the volume of questions started leaning toward the newest version
> of
> Plone (80% at least)?
>
> 4) Do we have the volunteer power to do minor security fixes to older
> versions?
>
> 5) How long will it be before the next major release? (1 or 2 years is an
> awfully long time to wait, and what's the harm in doing small security
> fixes
> to an older version in that time frame?)
>
> As far as 2.5 goes, it feels like we don't have clear metrics for making a
> clear decision. 4.0 feels very far away, and the fixes that have been
> applied to 2.5 haven't been onerous, as far as I can tell. I'd personally
> like to see 2.5 supported at least into the middle of next year (when the
> doc team can hopefully get into sync with the 3.0 folks), but that's just
> my
> two cents.
>
> - Veda
>
>
> On 12/19/08 2:15 PM, "Steve McMahon" <[hidden email]> wrote:
>
> > Hello Plone Foundation Members,
> >
> > The Plone Foundation Board would like to work on developing a good
> > policy for support of Plone versions prior to the current. It's become
> > clear that there are some differing community expectations on this,
> > and that there's not a clear decision-making process.
> >
> > Two of the common beliefs on support are: 1) that we'll support two
> > major versions at a time, or 2) that we'll support a major version for
> > a year after release of a new current version. There are also
> > different definitions of "support"; the most common is probably that
> > security fixes will be backported when technically feasible and that
> > documentation will be maintained.
> >
> > Our move to a longer gestation period for larger version changes is
> > probably the source of the confusion. It's probably not reasonable to
> > expect support for a prior release to always continue for two-or-three
> > years. On the other hand, when version changes are such a big
> > transition, a year may be too short.
> >
> > The board tries to keep out of decision-making about development, but
> > the foundation funds release managers and generally manages
> > non-volunteer resources. This policy will also impact marketing and
> > how Plone is perceived, and can be seen as bigger than individual
> > development decisions. The board will therefore take the
> > responsibility of defining this policy and making it official, but
> > only in close consultation with the Plone community.
> >
> > We'd particularly like to hear from the Plone Foundation membership,
> > and would welcome a membership-list discussion or mail to the board
> > <[hidden email]>. What should our support policy for
> > non-current versions be? What does "support" mean for non-current
> > versions. Should a policy be time-based or version-based?
>
>
> --------------------------------------------------------------------------
> ----
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs

------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs