[Bioc-devel] Attention Bioconductor Maintainers

[Robert Gentleman]

Gordon Smyth wrote:
> 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.
> 

Hi Gordon,

  We did think about doing that (the bumping only at change time), but 
all systems we could think of required some manual intervention/checking 
here, and we are run a bit thin - the project is a bit too successful 
for the available resources. But if you, or anyone else thinks up a 
different scheme before the next release we would be happy to change. 
This just seemed like it would be simplest for all - but a bit invasive, 
and for that we do apologize.

   Best wishes,
     Robert



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