Proposed critical step in cutting 1.0 release (or any major release)

Patrick R. Michaud pmichaud at
Mon Mar 2 17:41:51 UTC 2009

Based on the experience in TT #388, I think we need to add
"test Parrot against selected HLLs" as a critical step prior 
to making _any_ major release, including 1.0.  Here's the background...

Commit r37061 made a change that eliminated some PMC_str_val
items in src/packout.c; this change had the effect of
breaking the rakudo build.  (IMCC broke, not Rakudo.)

Most of the Rakudo developers and users are moving away 
from building or testing against Parrot HEAD -- we now
keep an internal pointer as to the version of Parrot that
we build against (which may lag some distance behind HEAD).  
Indeed, my understanding of the HLL development process is 
that HLL developers are generally expected to be working
against the monthly releases, not Parrot HEAD.

The only reason I caught the build breakage in this case was 
because I asked myself "Gee, I wonder if we still compile against
Parrot HEAD".  While I think it's very probable that someone
would have noticed this problem between now and March 17,
had the commit occurred closer to the release date it's
very possible that it would have gone unnoticed.  Had that
occurred, we would've been left with the situation that
Parrot 1.0 -- the one that we declare "stable" for multiple
months -- would've contained a bug that completely prevents
Rakudo from building.  

I suggest that we add a "critical" ticket for each of
the major releases whereby we verify that the major HLLs
can still be built against the code being considered for
the release, or at least that we can positively identify
that any problems are in the HLL code and not something
that requires a Parrot internals fix (as was needed for


More information about the parrot-dev mailing list