[Perl-workflow-devel] Fwd: [rt.cpan.org #40750] Version mismatch between module and tarball

[Jonas B. N. <jo...@gm...>]

Hola,

We have received a RT, what are your thoughts on the subject.

I do prefer module and distribution to live separate lives, but again  
it makes in pretty impossible to trace back to what distribution the  
packages come from or?

I am running this by the module-authors mailing list for advice,

jonasbn

Begin forwarded message:

<snip>
> Date: 10. nov 2008 16.30.03 GMT+01:00
> To: undisclosed-recipients:;
> Subject: [rt.cpan.org #40750] Version mismatch between module and  
> tarball
> Reply-To: bug...@rt...
>
>       Queue: Workflow
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=40750 >
>
> 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:
>> 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
>
>