Fwd: [Epo-ec-advisors] Some thoughts on areas to address in the EC

[Chris Prather]

On Fri, Jul 17, 2009 at 2:05 PM, jesse<jesse at fsck.com> wrote:
>
>
>
>> EPO::Core::$YYYY::Q[1-4] we will support 4 previous releases say 4
>> quarters or 4 previous releases with bug fixes and updates to modules
>> that exist in those releases. Additions and Deprecations can only
>> happen for *new* releases, but module updates and build will happen
>> for the last 4 releases unless someone pays to have a specific release
>> supported longer than that.
>
> What I think you've said above is that there will be a quarterly
> deprecation / new feature point and that there will be a one year
> maintenance promise for old releases....and that you're promising to
> keep four possibly fairly different releases maintained at any time.

Let me see if I can clear up my own thoughts on this. I think I gotta start
with defining some common terms:

EC-Release: This is a major release of the EPO-EC
dist (EPO::Core::$YYYY / EPO::Core::$YYYY::Q1)

EC-Release Cycle: This is the period between one EC-Release and the next (for
example the interval between EPO::Core::2009 and EPO::Core::2010)

Module: a specific CPAN dist inside a Distribution (Moose, DBIx::Class, etc)

> For something that's supposed to be stable and enterprisey, quarterly
> feature churn is going to scare people.  There are plenty of places that
> it takes 60-90 days to get things deployed.  Once deployed, production
> systems kick around for many years.  Saying that you'll kill support
> after 12 months seems draconian and unfriendly.

The principle I'm working with is to help encourage businesses to contribute
to the process and to minimize the level of effort that directly depends upon
volunteers. I'm trying to find a balance where the work required by volunteers
is mostly on the *new fun* stuff and the older stuff becomes as simple as
possible to maintain. This is mostly because as I've said else where, I fully
expect to be the "volunteer" right now.

> Saying that the previous year's stable version only gets security
> and critical bugfix updates after 12 months sounds a lot more like
> what a company depending on infrastructure would expect.

Hmm perhaps I wasn't clear with my thinking here. Only the next EC-Release can
have modules added or removed. Once a EC-Release Cycle is finished ... the
modules *in* that EC-Release are frozen in time.

So say EPO::Core::2009 has Moose ... we decide at some point to replace it
with Goose, that would happen with EPO::Core::2010. EPO::Core::2009's future
updates would have Moose versions updated for as long as it is supported but
wouldn't *ever* get Goose. This is the "bug fixes and critical updates" I had
in mind.

I also realize I'm hand-waving away the work required to maintain module
versions within a EC-Release.

> ...and then there's getting developers trained on the new version of things.
>
> That said, there's no reason there can't be monthly, weekly or even
> daily _releases_ of a given release series and there's no reason that
> an unstable ::2010 can't be available as soon as ::2009 ships.

Doing a frequent release of the Task:: module I think is imperative here if
nothing else as beta releases.

I keep thinking about this and I'm not so worried about the numbers right
(Quarterly vs Annual) now as I am the process. I think once we have the
process nailed down it can be scaled out to a time-frame people find
reasonable.

-Chris