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

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

Hello All,

After some consideration I have decided to comply with the lines  
suggested in the RT

The only impact will be that next public release will probably jump  
from what should have been 0.32 to 1.32 and from the on the VERSION  
will be maintained from the main module lib/Workflow.pm

This has already been committed to Subversion, so if you update to  
HEAD, the change should be reflected.

I was a bit to fast on the trigger however and I really want to  
address Robert Stockdale's patch for Workflow::State, but I have not  
gotten any feedback so this might have to wait or I will create a  
branch for releasing 0.32_5 development candidate.

I will however possibly readdress this patch in a mail to the list and  
Jim Brant in particular, since he was the driving for for the  
particular development, prior to taking these actions, since it is a  
one-line patch.

jonasbn

On 10/11/2008, at 22.06, Jonas Brømsø Nielsen wrote:

> 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
>>
>>
>