[Bioc-devel] Attention Bioconductor Maintainers

[A.J. Rossini]

It's a matter of control.  Sounds like a system that lots of people
(like me) will have strong opinions on. I won't share mine. See
"Bikeshedding" in the Jargon File/Hacker's Dictionary:

http://catb.org/~esr/jargon/html/B/bikeshedding.html

It won't break any version tracking.  But the proposal is incomplete
in that it isn't clear as to the exact timing for implementing your
proposal in the actual release cycle, since there ought to be
increments made when things are changed.

best,
-tony


On 5/21/05, Kasper Daniel Hansen <k.hansen at biostat.ku.dk> wrote:
> But why not revamp the version number completely. Let
>   x.y.z.w
> be the version number. Let x.y correspond to the R version, let z
> track the development and let w track release version changes. In that
> way a typical package would be
>   2.1.0.1
> at the current R release. Changes to the fourth number would reflect bug
> fixes, while development would result in an increase in the third
> number. Once the R version bumps, everything starts from scratch.
> 
> Ok, this would break a lot of version tracking (that is a bit of an
> understatement), but at least it would provide some version tracking in
> the future, which is consistent with R.
> 
> Well, I am just throwing ideas around. Ignore them at will :) But
> basically I can see the point in bumping version numbers when R/BioC
> is bumped.
> 
> Kasper
> 
> On Sat, May 21, 2005 at 09:42:40AM +0200, A.J. Rossini wrote:
> > I think in this case I agree with Seth/Robert -- at the very least, we
> > probably should consider bumping the R requirements to track the
> > latest R (though NOT until near release).  It would be a complete
> > waste of time to backport core pieces of BioC back to the previous
> > version of R, for example, especially if dependent on core features
> > (or for example, using new features in the packaging files.  So there
> > should be minimal changes made, at the least.   Whether this merits
> > x.y.z -> x.(y+1).0, I think is more aesthetic than real.
> >
> > best,
> > -tony
> >
> >
> >
> > On 5/21/05, Robert Gentleman <rgentlem at fhcrc.org> 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
> > > >
> > > >
> > > > _______________________________________________
> > > > Bioc-devel at stat.math.ethz.ch mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > > >
> > >
> > > _______________________________________________
> > > Bioc-devel at stat.math.ethz.ch mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >
> >
> >
> > --
> > best,
> > -tony
> >
> > "Commit early,commit often, and commit in a repository from which we can easily
> > roll-back your mistakes" (AJR, 4Jan05).
> >
> > A.J. Rossini
> > blindglobe at gmail.com
> >
> > _______________________________________________
> > Bioc-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> --
> Kasper Daniel Hansen, Research Assistant
> Department of Biostatistics, University of Copenhagen
> 
> 


-- 
best,
-tony

"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

A.J. Rossini
blindglobe at gmail.com