[Bioc-devel] Attention Bioconductor Maintainers

[Gordon Smyth]

Hi Robert,

OK, yes, I see now the problem that you are addressing. I had been viewing 
the release version as essentially fixed and not permitting version number 
increments. However, if you do allow bug fixes and hence version increments 
to the current release, I agree that you need to bump up the devel version 
numbers (with a slower moving counter) so that the release version number 
always stays below the devel version. It would be slightly better to do the 
bumping only when the first change is actually made to the devel version, 
but people will probably forget to do so at this stage, so I agree that 
your pre-emptive bumping is a good idea.

Regards
Gordon

At 11:17 AM 21/05/2005, Robert Gentleman wrote:
>Hi Gordon,
>    Do you have an alternative?
>The problem, as I see it is the following:
>   As R changes we track and use, and some times are the reason for, those 
> changes. So packages and developers need to do that on the devel arm, it 
> is going to morph into the next BioC release and be compatible with the 
> next release of R. If they do not bump their version numbers quite 
> substantially, then there are problems with version numbers between 
> release BioC, which must allow bug fixes, and hence must allow version 
> number increments, and those on the devel arm, which we hope will have 
> version number changes because people are active and adding new features 
> etc. I think it would be very confusing to start interlacing these - but 
> we are very happy to see anything that developers want and that will help 
> to provide for both a happier developer experience and a happier user 
> experience.
>
>  This seemed to be the easiest way to achieve that, but certainly not the 
> only one - so please let us know what you think would work better. If we 
> can agree soon then we can implement it before too much divergence.
>
>
>  Thanks
>    Robert
>
>
>Gordon K Smyth wrote:
>>Hi Seth,
>>I agree with you that the distinction between Bioc release and devel can 
>>be confusing and needs to
>>be clarified, but I don't think that this is the way to do it.  The 
>>trouble with incrementing all
>>the package numbers is that it breaks the basic principle that version 
>>numbers track changes in
>>packages.  It implies to a user that the packages have been changed, when 
>>they have not.  A user
>>will not be able to tell whether they should go to the trouble of 
>>converting to the devel version
>>or not.  It could even be considered to be a bit dishonest to give the 
>>impression that all the
>>packages have been updated and (by implication) improved when actually 
>>they haven't.
>>Anyway, this isn't a request for special treatment.  I think whatever you 
>>do you should do to all
>>the packages, and I'll work-around whatever.
>>Gordon
>>On Sat, May 21, 2005 9:53 am, Seth Falcon said:
>>
>>>Package version numbers have been "bumped".
>>>
>>>In order to distinguish between the Bioconductor 1.6 release branch
>>>and the devel version of Bioc packages, I have made the following
>>>version number change to all packages included in the 1.6 release:
>>>
>>>x.y.z  ==>  x.y+1.0
>>>
>>>For example, Biobase was released at 1.5.12.  It's new devel version
>>>is 1.6.0.  This way, patches on the release branch can continue to
>>>increment the z number without any confusion with the devel version of
>>>the package.
>>>
>>>If you strongly object to this change in your package version number,
>>>please contact me so that we can work out a compromise.
>>>
>>>Thanks,
>>>
>>>+ seth