[Bioc-devel] Version numbering rules and other policies

[Martin Morgan]

Hi Chengyang -- welcome!

1. yes, there can be multiple commits and then a bump of z. Only when z is incremented does a new version propagate from the build system to the public repository available to end users. It is probably best practice to bump the version z on every commit -- there is no shortage of version numbers!

If you introduce very substantial changes, then it is appropriate to increment, in the devel branch, to, e.g., 1.99.0, 1.99.1, 1.99.2, ... so that at the next release the package will be automatically bumped to version 2.0.0. Very few packages are at version 2.0.0 or above.

2. Yes, add and remove dependencies as appropriate. Make these sorts of changes in the 'devel' branch.

3. New functions can be added to the devel branch at any time.

4. Your package is only available in devel at the moment, so only has a 'master' branch. We will add a RELEASE_3_9 branch on April 29, immediately before the release on the 30th. See https://bioconductor.org/developers/release-schedule/.

5. If you break your package and don't fix it before the release, then we can't make it available to end users so it won't be available. Some time early in the next release cycle we'll review packages that have not built and you'll be contacted with an opportunity to fix it. But it sounds like you are a responsible maintainer and you will fix your package before we have to ask you to fix it. So please make improvements to your package now. Note that on April 26 we have the Biocondcutor 'release candidate', and any changes you make between then and the release should be significant bug fixes and documentation changes.

Martin

On 4/8/19, 10:50 AM, "Bioc-devel on behalf of Chengyang.Ji12" <bioc-devel-bounces using r-project.org on behalf of Chengyang.Ji12 using alumni.xjtlu.edu.cn> wrote:

    Hi,
    I�ve been further going through the �developer resources� as my package just got accepted. And I have few things to ask/confirm.
    
      1.  About the versioning scheme (x, y, z). Can we increment �z� by 1 for multiple commits? Does the scheme imply that we only change �z� unless the package has major changes and we bump �x� by setting �y� to 99?
      2.  Speaking of major changes, are we allowed to add/remove dependencies in the later version of our package? Like when re-implementing the functionalities.
      3.  Deprecating/removing a function takes three release cycles but what about adding new functions and making changes to internal functions? Any rules to apply?
      4.  For the remote repo host by Bioconductor, I understand that we have access to �devel� and �release� branches which are master and RELEASE_X_Y so to speak. We can create new features on �devel� branch but only bug fix is allowed for �release�. Am I right on this?
      5.  I now only have �devel� branch available and the build report claims good. Will my package be �kicked out� if the new commits I make fail the build before the release?
    Point me out if I got anything wrong. It�s exciting to be able to make contributions to Bioconductor and I want to make my package better, starting by learning the policies.
    Regards,
    Chengyang
    
    	[[alternative HTML version deleted]]