Front page | perl.perl5.porters |
Postings from October 2009
Re: The Great Pumpkin
October 31, 2009 17:10
Re: The Great Pumpkin
Message ID: 20091101001027.GH22548@bestpractical.com
On Sat, Oct 31, 2009 at 02:22:43PM -0600, Curtis Jewell wrote:
> Considering that I'm (because of Strawberry) going to be needing to keep
> up to date with you as we go through this, here is what I'm going to be
> doing so I can feel comfortable releasing an adequately-tested version
> of Strawberry Perl 5.12.x:
Fantastic. If there are things we can do to help keep strawberry in the
loop or up to date, please do raise them on p5p. (That goes for other
vendors who ship Perl as a product, with a product or make art with the
source code. Whatever. If the Perl release matters to you, then your
involvement in the release process will help make sure everything goes
> I should be able to build a "Strawberryish" 5.11.2 after the United
> States Thanksgiving [Nov 26th] if 5.12.0 RC1 is not available at that
> point. (I may still be making the big changes
> [relocatability/merge-module use/64-bit] at that point.)
*nod* How much do you tend to need to massage the Perl distribution to
get it into shape for Strawberry? Are things that would make sense to
bring upstream to the core?
> > * Yell at people to test the RC
> And to help in that testing, I'll commit to making a "Strawberryish"
> 5.12.0RC1 available within 10 days of the RC1 tarball's release (it
> should be sooner, but the time frame you're aiming for may create
> problems with other commitments.)
Understood. Do note that that timeframe depends entirely on what people
find for bugs. If we can get a strawberryish distribution that we can
drop the RC source code into as it stabilizes, that would be excellent.
How plausible is it for an arbitrary porter to build a distribution that
is identical to strawberry from a given git revision?
> If we're aiming for Christmas - or even for Coptic Christmas - for this,
> then I'll commit to having a beta released within a week to 10 days.
> Since that beta would come during the RC period for Strawberry's January
> release, I won't do a non-beta release for January, most likely. Part
> of the reason is that 5.12.0 would be beta-tested as both 32-bit and
> 64-bit versions, as mentioned in previous messages.
Given Strawberry's focus as an end-user binary distribution, I'm
thrilled that our target date (which depends entirely on us getting all
our RC blockers taken care of quickly and not running into more) means
that we just miss one of your release dates. That makes it _very_ easy
to tell people that they should be testing the new release and to get
comfortable with it before foisting it on the Strawberry-using world ;)
> > * Yell at people to test 5.12.0
> > * Ship 5.12.1RC1 30 days after 5.12.0 with whatever bugfixes, cleanups,
> > improvements were found to be necessary when users _actually_ test
> > the release.
> In this case, then Strawberry WON'T end up doing a full release for
> 5.12.0, as I'm going to have to do a build for this RC before I would
> feel comfortable taking a new release of 5.12.0 out of beta as far as
> Strawberry is concerned. [I prefer to have a month of "beta" time for
> the bugs to shake out - 2 weeks at an absolute minimum]
That, again, doesn't bother me too much. The goal of getting the first
update to 5.12 out in that kind of timeframe is to make sure that any
bugs that shake out in the first stable release of 5.12 get sorted out
quickly and end up in as few production deployments as possible.
> > * Ship 5.12.1 with a methodology similar to that used for 5.12.0
> This would probably end up being the release that would be paired with
> 5.10.x for a non-beta release for the April 2010 cycle. I'm in the
> process of deciding whether to give up on building 5.8.x versions of
> Strawberry for January... (if I can make Strawberry 22.214.171.124 "any
> location" installable using -Duserelocatableinc for January 2010, then I
> probably will. If not, then April 2010 for sure.)
> > * branch maint-5.12 and reopen the blead tree
> > Assuming that we're happy with the results, my intent is that we spin
> > up the same process for Perl 5 Release 14 next October or November.
> If you decide on November 2010 to start the "Perl 5 Release 14" process,
> then start earlier in the month, please. That way, I have enough time
> to build RC's in the "big changes" month and hopefully have a final
> version that I can beta-test, at worst, late in the "beta-test" month.
> October would be better. But I'll live with whoever the pumpking at that
> time decides.
Definitely! That's part of why I announced the intent _now_.