I have already had to argue this point with the author of XML::DTD, but
to rehash, I am rebuilding a bundle for our application since we changed
Perl distributions. Out of the 70 modules I downloaded, his and yours
is the only ones I had a problem with.
When users download workflow, they are not thinking what sub modules are
included with it since they are using 'Workflow' and not
'Workflow::something' most of the time. So when I looked up the
Workflow in our bundle and saw that it was 1.32 I went to download 1.32
and not 0.31. This is a problem because you now have several releases
of Workflow that are labeled 1.32 with the only way to tell them apart
is to dive into each sub module and look up the versions of them (I
shouldn't have to argue how much a pain that is). There are no problems
keeping different versions of the sub modules in the module, but when
you make a change to one of them, you are making a change to Workflow as
a whole, thus its version needs to change to reflect the update. Now we
just happen to be in control of what modules we install, but if we are
on a shared system how are we to know what version of Workflow the admin
has on the box (if even they know)?
You make mention that it doesn't make sense due to Workflow's size and
arch, but I'm not buying that. When you make a release you should be
running through a checklist of stuff to do and one of the things on that
list is to make sure your gateway module version and docs reflect the
module as a whole. What versions are internally need to be kept track
with your RCS. Case in point:
CGI
Dbi
XML::LibXML
Wx
I wouldn't consider any of them small. If you don't want to keep your
module version and release verison in sync then you need to update your
documentation to indicate what release version your users are looking at.
Another rehash from my XML::DTD argument. I forwarded your response to
my 12 coworkers and they agree that the version number to workflow needs
to reflect changes to the module as a whole.
On Mon Nov 10 06:26:44 2008, JONASBN wrote:
Show quoted text> Please note that the distribution version is not the same as the
> Workflow module version number.
>
> We version these differently so changes to the Workflow module can be
> identified in the modules version number.
>
> Some releases of the distribution does however not require changes to
> the Workflow module, since the distribution consist of a large number of
> files, so the two numbers indicate different things.
>
> For smaller distributions it is an idea to have the two numbers aligned,
> but for Workflow this does not make sense.
>
> I checked the source back to the initial revision and these numbers have
> been not been aligned it seems - that the module and distribution have
> had the same number at some point must be coincidence.
>
> Separating the two is however the chosen strategy because it makes sense
> in the case of the Workflow distribution due to it's size and architeture.
>
> jonasbn
RT for rt.cpan.org