[Bioc-devel] Newly proposed version bump plan

[Seth Falcon]

Hi Korbinian,

(cc'ing bioc-devel)

On 30 Sep 2005, korbinian.strimmer at lmu.de wrote:
> Seth Falcon wrote:
>> So, are you ok with making sure GeneTS gets updated in CRAN after
>> the BioC release?
>
> Sure I can do this for the next release.  However, I still find it
> not a good idea to force this version numbering scheme upon all
> packages in BioC.  Probably a better idea, at least in my opinion,
> would be to restrict this only to the core BioC packages.

It may surprise you to know that there are no "core BioC packages".
Other than Biobase, there is no defined set of core packages.

The impression of "core", I suspect, stems from the subset of package
developers do work more closely with eachother and attempt to
coordinate improvements in their packages.  This happens because the
developers have something to gain in the collaboration.  No official
(or unofficial) sanction is required to become more involved.

> This is also how it is handled in other large open source projects.
> For instance, I am running Gnome 2.10 here on my computer, and
> all the main components have this version number, but not the
> optional ones: e.g. the calculator has version 5.5.41...

And this makes sense for projects that distinguish core from contrib,
but as yet, Bioconductor makes no such distinction.

> In any case, one of the main reason for this new numbering scheme
> seems to be that user can identify easily which packages belong to
> a stable BioC release, and which are development versions.
> I am wondering why this is actually a problem:  I guess most
> people who use BioC will download only the stable version
> anyway.  And if you choose to live on the bleeding edge you
> usually know what you are doing.  In addtion, if you'd like
> to figure our whether a package is stable or not, what is wrong
> with simply  looking it up in the list that *defines* the current
> stable BioC release..

Yes, the version scheme's primary purpose is as a convenience to users
(and other developers) to make it easier to distinguish release from
devel.  When a user posts a question to the bioconductor mail list and
actually remembers to include output from sessionInfo() I would love
to be able to see at a glance whether they are using all release, all
devel, or mixing and matching.  Yes, I could look up the version
numbers for 6 different packages, but...

> So in summary, I think it is a good idea for the core components
> where all the developers work closely together, but not for the
> many more 3rd party packages on BioC  (for comparison: imagine
> the CRAN archive would force a change of version number in
> all the 500+ packages every 6 months..).

<start BioC theme song>

The Bioconductor project is something more than a simple code
repository.  We encourage collaboration between contributors because
we believe this accelerates innovation and results in software that is
more reliable and easier to use.  

The release cycle is one way the project supports collaboration
between packages.  Without a shared release cycle, such collaboration
would be much more difficult.  Shared release cycles impose version
numbering issues.  

While the project welcomes all contributions from the bioinformatics
community, we ask for some cooperation to help realize some of the
projects goals.  If what one wants is only a place to post one's
package, then a "simple" repository like CRAN is the thing.

> Just my 2 cents ;)

And my 4 cents, I'm afraid (sorry for the length).  Thanks for sharing
your thoughts and giving me an opportunity to clarify some aspects of
the project.

Best Wishes,

+ seth