Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Workflow CPAN distribution.

Report information
The Basics
Id: 40750
Status: resolved
Priority: 0/
Queue: Workflow

People
Owner: jonasbn [...] cpan.org
Requestors: admiral.grinder [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.31
Fixed in: 1.32



Subject: Version mismatch between module and tarball
Download (untitled) / with headers
text/plain 174b
Need to fix the filename for the module to reflect what version of this module is. Currently the module and docs says it is v1.32 but CPAN and the tarball filename says 0.31
Download (untitled) / with headers
text/plain 881b
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
From: admiral.grinder [...] gmail.com
Download (untitled) / with headers
text/plain 2.9k
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
Subject: Re: [rt.cpan.org #40750] Version mismatch between module and tarball
Date: Mon, 10 Nov 2008 22:00:59 +0100
To: bug-Workflow [...] rt.cpan.org
From: Jonas Brømsø Nielsen <jonasbn [...] gmail.com>
Download (untitled) / with headers
text/plain 3.4k
Hello, I will need to run this by the developers list and I will probably mail the module-authors list as well to inquire about best practices. I will reopen the ticket until I make up my mind about how to proceed. jonasbn On 10/11/2008, at 16.30, admiral.grinder@gmail.com via RT wrote: Show quoted text
> 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
> >
Subject: Re: [rt.cpan.org #40750] Version mismatch between module and tarball
Date: Wed, 12 Nov 2008 18:05:31 +0100
To: bug-Workflow [...] rt.cpan.org
From: Jonas Brømsø Nielsen <jonasbn [...] gmail.com>
Download (untitled) / with headers
text/plain 3.5k
Hello, After much consideration and talking to a few people, I have decided to implement the versioning strategy requested by you. Next forthcoming release will be supporting the scheme. I hope my hesitation did not cause you too much agony. Take care, jonasbn On 10/11/2008, at 16.30, admiral.grinder@gmail.com via RT wrote: Show quoted text
> 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
> >
Download (untitled) / with headers
text/plain 411b
Hi, The newest release of Workflow (1.32) addresses the problem you report. It has just been uploaded to CPAN. I have given the problem you reported a lot of thought and I consider implementing a Perl::Critic policy to ensure a better practice with these version numbers, since the capability to back-track is quite important. Thanks for taking the time to report the issue, jonasbn, maintainer of Workflow


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.