NEWS update
Reini Urban
> [release] Updates to NEWS from commit log since last release.
Since allison single-handedly, without any public discussion,
removed the below described "Bytecode Compatibility".
docs\project\support_policy.pod:
"=head2 Bytecode Compatibility
In future releases, we might make changes to the bytecode format that
would prevent bytecode generated on one supported release from running
on a later supported release. These changes will follow our usual
deprecation guidelines, with adequate advance notice."
It should be properly noted in NEWS that the above pbc version portability
is now, starting with 1.1.0, officially not supported anymore.
It was already removed with 1.0, but 1.1.0 is the first release which
breaks this promise.
ops were removed, PBC_COMPAT changed, and the previously coded and described
pbc version compatibility was removed. So the above promise is
violated. Every single
ops or pmc change leads now to pbc incompatibility without any
deprecation period.
1.1 broke it what what should have been broken with 1.4.
BTW, I still cannot believe that allison was allowed to get away with that.
Normally such a project leader, lacking technical and project leading
capabilities
would get fired immediately or it would lead to a prominent split.
However, a "pparrot" (Portable Parrot) split is out of my intentions.
I just left.
The damage is already done and irrevocable.
Not talking about the make install mess, that 1.0 and 1.1 will still
not lead to any language release, since it is technically impossible
without any serious patches. For parrot and for the languages. I
posted links to patches to fix that, but saw no reaction.
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot
=> parrot and pipp 1.0.0 and rakudo-200903
Such problems should be marked blocking in a normally lead project.
Anyway, I see no proper fitting NEWS line for this problem (" +
parrot languages still not installable"), so no patch for that.
--
Reini Urban
Allison Randal
> 2009/4/19 <fpe...@svn.parrot.org>:
>> [release] Updates to NEWS from commit log since last release.
>
> Since allison single-handedly, without any public discussion,
> removed the below described "Bytecode Compatibility".
>
> docs\project\support_policy.pod:
> "=head2 Bytecode Compatibility
> In future releases, we might make changes to the bytecode format that
> would prevent bytecode generated on one supported release from running
> on a later supported release. These changes will follow our usual
> deprecation guidelines, with adequate advance notice."
>
> It should be properly noted in NEWS that the above pbc version portability
> is now, starting with 1.1.0, officially not supported anymore.
> It was already removed with 1.0, but 1.1.0 is the first release which
> breaks this promise.
>
> ops were removed, PBC_COMPAT changed, and the previously coded and described
> pbc version compatibility was removed. So the above promise is
> violated. Every single
> ops or pmc change leads now to pbc incompatibility without any
> deprecation period.
> 1.1 broke it what what should have been broken with 1.4.
It meets the promise, because in 1.0 there was a deprecation notice.
> =head1 Bytecode
>
> =over 4
>
> =item packfile structure [eligible in 1.1]
>
> L<https://trac.parrot.org/parrot/ticket/451>
>
> =item opcode numbering [eligible in 1.1]
>
> L<https://trac.parrot.org/parrot/ticket/451>
>
> =item PMC numbering [eligible in 1.1]
>
> L<https://trac.parrot.org/parrot/ticket/451>
>
> =back
We knew we had some substantial work to do in ops, PMCs, and the
packfile format in the next few months, and we made that explicit to our
users. Around 2.0 or 3.0 we'll start to be able to guarantee bytecode
compatibility between one supported version and the next. We can't right
now, and that's okay. This is an early stage in the adoption cycle, and
we don't have many production users to support.
> BTW, I still cannot believe that allison was allowed to get away with that.
> Normally such a project leader, lacking technical and project leading
> capabilities
> would get fired immediately or it would lead to a prominent split.
It's okay to disagree with the leader. Discussion is an important part
of driving innovation. But, it is entirely inappropriate to claim that
because someone disagrees with you they lack knowledge or experience.
It's equally likely that you lack knowledge or experience, so best to
keep such personal claims entirely out of the conversation.
> However, a "pparrot" (Portable Parrot) split is out of my intentions.
> I just left.
> The damage is already done and irrevocable.
I'm sorry to hear that, and will disable your commit access. We wish you
the best of luck, and you are, of course, always welcome back.
I highly recommend the following talk to everyone:
http://video.google.com/videoplay?docid=-4216011961522818645
> Anyway, I see no proper fitting NEWS line for this problem (" +
> parrot languages still not installable"), so no patch for that.
We're working on it, and making progress. We'll have it ready for 1.4.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev