The Core Problem with Parrot Version Numbers

[Mark Glines]

Todd Olson wrote:
> At 09:14 -0800 2009-02-20, Allison Randal wrote:
>> People will look at it and instantly understand "Ah, 2.0 is more recent than 1.0, I might consider upgrading." Which is all that really matters.
> 
> 
> As one who builds systems out of software like Parrot
> what really matters to me is
> 
>    "How badly will things that depend on Parrot break if I drop 2.0 in for 1.0?"
> 
> Experience suggests three different answers are common:
>     a) nothing should break
>     b) nothing should break, but 2.0 goes beyond 1.0 so you cannot down grade
>     c) things will break, things that depend on Parrot require rework
> 
> Is there an easy programatic way to extract this information when
> comparing two Parrot releases?

Yes, that's what the 6-monthly deprecation boundaries are for.  So
normal monthly releases would be classified as "a" or (more likely) "b"
in your above list, whereas when you cross the boundary from [Bird name
beginning in A] to [Bird name beginning in B], that crosses a
deprecation boundary, so it would be considered "c".

Mark