In regards to http://perlcabal.org/syn/S11.html#Versioning I have recently
considered that it may be deficient in addressing a possibly-common situation,
and I'm looking for input on how to handle that situation, either for a best
practice that works within the current model, or on enhancements to the
versioning spec to better handle it.
For background, right now there are mainly 3 parts to a module name (I'm
ignoring "from" for the moment), which are "name", "auth", "ver", where each
part of the sequence is evaluated in the context of the parts before it.
Now the purpose of "auth" is to distinguish between different
entities/authorities/authors that release a version of Perl or a Perl module,
and "ver" is the sequential numbering scheme where each "auth" has its own.
The question I have is what to do when a single same authority wants to release
multiple forks or branches of the same module, each presumably targeting a
different use case, and the version numbers for each fork/branch are not
supposed to be interrelated.
For example, say a single authority has a standard version of a project intended
to be used over the long term and represents a more idealized version of the
project, but that may have greater issues of compatibility with parts of the
wider ecosystem, and that will take more time to fully spec and develop. So say
they also come up with another version of the project that is more of a
compromise between the idealized version and short-term pragmatism; the latter
is easier to use and integrate with an existing ecosystem, and copies more of
existing approaches than formulating an improved way. These two versions, while
being a lot alike, may have some fundamental differences and mutual
incompatibilities, and each is intended to be used for years; the less-idealized
version cuts corners and attaches features in ways that might not be the best
but that are like what people are already accustomed to and require less
adaption. Long term, they would grow together.
Essentially the situation is exactly the same as a project fork, except that the
fork is done by the same author as what is being forked.
Now conceptually these 2 things are still the same project and so simply giving
them different "name", creating one version as a different-named project, may
not be the best approach, as each in their own way they are both the original,
and also for people just using the common subset of their abilities, they are
still drop-in interchangeable with each other, though if two different parts of
the same larger project depend on both forks, they'd need differentiating.
A similar scenario is that an active project may have several branches for
trying out future development options, and they may want to do actual releases
of distinct branches to make it easier for the wider community to try them out
for awhile and see what works best, especially if a branch has a long life due
to its complexity, perhaps like major version 1 and candidate major version 2,
or just stable and dev.
Assuming we want to keep the same "name", I thought of a few distinct
resolutions.
One option is to add another part to the long name, maybe "branch", so say you
can then have, in order of dependency/determinacy:
Dog:auth<JRANDOM>:branch<IDEALIZED>:ver<1.2.3>
Dog:auth<JRANDOM>:branch<COMPROMISED>:ver<1.2.3>
Now doing it like that also provides a different solution for separating dev and
stable releases. Eg, instead of say appending _01 or something to a version,
the versions can stick to being numbers, and we could have:
Dog:auth<JRANDOM>:branch<PRODUCTION>:ver<1.2.3>
Dog:auth<JRANDOM>:branch<EXPER_FEATURE_X>:ver<1.2.3>
I think there are a lot of good uses for such a version spec extension actually.
Now other options to support this is to perhaps invent another "auth",
pretending someone else made this and then the existing design rules apply. So
say you could have ":auth<JRANDOM>" for the main version and
":auth<JRANDOM/EXPER>" for a side version. But I find this distasteful.
Perhaps a bit better is to further enhance "ver", such as with
":ver<EXPER_X/1.2.3>", and that *might* be superior to my first proposal for
longetivity and flexibility, but truly now I think my first suggestion of adding
"branch" and leaving "ver" and "auth" as is would be better.
So, what do the rest of you think about this?
-- Darren Duncan
