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

[Chris Prather]

I missed the list.

---------- Forwarded message ----------
From: Chris Prather <perigrin at gmail.com>
Date: Fri, Jul 17, 2009 at 1:54 PM
Subject: Re: [Epo-ec-advisors] Some thoughts on areas to address in the EC
To: jesse <jesse at fsck.com>


On Fri, Jul 17, 2009 at 1:38 PM, jesse<jesse at fsck.com> wrote:
>> > Designing for deprecation and evolution is very important.  What's the
>> > plan for releasing new versions of the extended core _without_ things
>> > that were previously there?
>>
>> I haven't worked out a formalized one yet except a rough idea of
>> deprecation cycles and regular releases. I think a policy of deprecate
>> for N release and then removal is the workable rough idea in my head.
>> Better suggestions?
>
> What comes to mind is something like this:
>
> - Deprecations (or really, "Extended Core Best Practices") are calendar based, not release-count based.
> - EPO::Core (or whatever it's actually called) would depend on
>  EPO::Core::$CurrentYear (say EPO::Core::2009).
> - Nothing in EPO::Core::2009 would ever be removed from future releases
>  of EPO::Core::2009, though EPO::Core::2010 might finally remove Moose
>  and replace it with Goose or something.
> - The recommended deployment practice would be to depend on a specific
>  model-year of EPO::Core::, thus ensuring that if you tried to redeploy
>  your system after the hardware smokes 36 months down the line, you
>  don't get screwed.
>
> How on crack am I?

I'm reminded of the Postgres description from David Wheeler recently
http://justatheory.com/computers/databases/postgresql/perl/pg-vs-perl-dev.html.

Having releases and deprecations be time based, but having some kind
of support policy for N previous releases where bugfixes and updates
get applied could be workable. Having a moving window of supported
releases could be a stick to have companies donate time/money to keep
specific releases supported.

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.

That doesn't sound too onerous, but it keeps the pressure on moving
forward without sacrificing the ability to lock yourself in for a
longer period of time.

My current plan is once started to release a new Task:: module Monthly
... and a new binary distribution quarterly. Is that too aggressive?
Not aggressive enough?

-Chris