which parrot version to package?

after some lengthy discussions finding the final versioning scheme for parrot, allison finally decided that parrot will use the following version numbers:
  • 1.0 (March, deprecation point)
  • 1.1 (April)
  • 1.2 (May)
  • 1.3 (June)
  • 1.4 (July, deprecation point)
  • 1.5 (August)
  • 1.6 (September)
  • 1.7 (October)
  • 1.8 (November)
  • 1.9 (December)
  • 2.0 (January, deprecation point)
  • 2.1 (February)
  • 2.2 (March)
  • 2.3 (April)
  • 2.4 (May)
  • 2.5 (June)
  • 2.6 (July, deprecation point)
  • 2.7 (August)
  • 2.8 (September)
  • 2.9 (October)
  • 2.10 (November)
  • 2.11 (December)
  • 3.0 (January, deprecation point)
the stable versions will be the deprecation points - that is, 1.0.0, 1.4.0, 2.0.0, 2.6.0 and 3.0.0. this means that those versions may have some bugfix releases during their support lifetime (1 year), but only for very limited stuff (security or other critical problems). everything is described in parrot's support policy.

as parrot packager for mandriva, this is good to know. however, i don't really know what to do: should i package the stable versions? or should i update the package for each new devel version?

since parrot is quite in flux those times, version 1.0.0 (which is 3 monthes old) is really useless... if you add that almost nothing production-ready relies on it currently, i have decided to update the package on a monthly basis. which means that rpm for parrot 1.3.0 is available on cooker right now.

but let's think forward a bit... when rakudo will be able to use an existing parrot, when perl 6 will be in production, i won't continue like that: i'll just stick (of course) with the production releases... but when will this point happen? when will i switch from devel to stable versions? this remains to be seen...


  1. Just keep pushing releases, people who cares will help you stibilize them?

  2. @ruslan: yup, that's what i'm doing. i'll see when rakudo will be able to use a live parrot.