perl5i has to provide both stabilty, so it can be used in production without having to rewrite your code every release, as well as continuing ability to experiment including breaking compatibility with itself. This is the paradox Perl 5 finds itself in.

To support this it has been proposed that perl5i use an X.Y.Z versioning scheme. A change in X indicates a deliberately incompatible change which breaks a documented feature. Y is for new features (adding new methods and functionality). Z is for bug fixes.

Then users can write "use perl5i as => 5" which causes perl5i to act like version 5.Y.Z. This "version stapling", as I've been calling it, lets one use perl5i guaranteeing stability while allowing us to still change things.

An implementation would be to have perl5i.pm be nothing more than an import() routine which selects the proper version. The rest of the distribution is under lib/perl5i/$X/. Each $X directory contains a complete copy of the distribution. This will avoid having to write lots of "if version X do this, else if version Y do this, else if version Z do this" code. It allows older versions to simply fade away.

The downside of that approach is A) we need to ship all the old versions, and depend on their dependencies, which could get rather large, B) we can't use cherry-pick to pull bug fixes from one major version to another.

An alternative would be a syntax like "use perl5i::5". This would do the same as the above, but then users can depend on perl5i::5, it can be split off into its own distribution once it's stable (ie. dead) and branch. Doesn't solve the cherry picking problem.

More specific version numbers like "use perl5i as => 5.2" will probably not be supported as keeping them all in line will be difficult.

Either way, if we do this the current version on CPAN will have to be pulled and a nasty version sheer will occur for anyone who already has it installed necessitating a manual update. I'm willing to live with that this early in the project for the benefit.