[Bioc-devel] Please bump version number when committing changes

Dan Tenenbaum dtenenba at fhcrc.org
Sat Sep 6 04:51:15 CEST 2014 

I'd add another scenario which is that every night the build system builds whatever was checked in.  This can cause extensive and confusing breakage in the build system. The build report does indicate svn revision number and timestamp of last commit, but one tends to look at the version number. As Kasper points out, though, packages that haven't been bumped do not propagate, and neither do packages that fail to build or check as a result. So the confusion is limited to the build system. 

My initial email was motivated by noticing that several people had made obvious fixes without bumping versions, clearly not understanding that they needed to do so. In our discussion of the finer points let's not lose sight of this. 

Dan

On September 5, 2014 7:06:03 PM PDT, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote:
>Before we go and invent all kinds of stuff, is this a real problem that
>we
>need to spend resources thinking about?
>
>Dan's original post was about 2 people who check out devel from svn may
>see
>the same version number, but have different versions of the code.  I
>acknowledge that this is theoretical possible.  In the rare situation
>where
>this might matter, it would be better to compare svn revision numbers. 
>And
>does this really happen with any frequency, I mean, the people who
>install
>packages from devel using svn must be very limited for a given package
>(perhaps I am different, but I only do it occasionally, and almost
>always
>for my own packages or if I depend on a package where I have identified
>an
>issue, the other author has fixed it and I need to test now and not
>tomorrow).
>
>With the current build policy, as I understand it, two people each
>installing not from svn, but from the published tarball throguh
>biocLite,
>is guaranteed to have the same code if they have the same version.
>
>The remaining issue is if one user installs from svn and one user from
>a
>tarball.  But I think everyone who does svn just need to understand
>that
>this can happen.  The affected users must be rather limited.
>
>One version of the problem, which I can see being confusing, is if an
>author pushes a bug fix to svn, but does not bump DESCRIPTION.  Then I
>could see some unfortunate discussion between the developer and a user,
>but
>that really comes down to lack of understand of the build system for
>the
>developer. While I am sure it happens, the solution in my opinion is
>better
>education for the developers about the build system.
>
>Best,
>Kasper
>
>
>
>On Fri, Sep 5, 2014 at 9:48 PM, Michael Lawrence
><lawrence.michael at gene.com>
>wrote:
>
>> As Pete and Ryan have pointed out, it seems that the version control
>system
>> should somehow ease the burden of the developer here.
>>
>> Let's look at this from the github perspective, since it is likely to
>be
>> the primary hosting mechanism for the foreseeable future. Just
>thinking out
>> loud, if R could somehow dynamically ascertain the version of a
>package at
>> build time, it could query the git checkout for a version. A simple
>> algorithm that I have found effective in non-R projects is to
>consider git
>> tags, which on github equate to releases. If the repository state is
>*at*
>> the tag, then use the tag as the version. If the state is ahead of
>the most
>> recent tag, then use the tag + latest commit hash. I wonder if R
>could
>> support this by allowing a path to an R script in the version field?
>>
>>
>>
>> On Fri, Sep 5, 2014 at 6:27 PM, Vincent Carey
><stvjc at channing.harvard.edu>
>> wrote:
>>
>> > On Fri, Sep 5, 2014 at 7:50 PM, Peter Haverty
><haverty.peter at gene.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > I respectfully disagree.  One should certainly check in each
>discrete
>> > unit
>> > > of work.  These will often not result in something that is ready
>to be
>> > used
>> > > by someone else.  Bumping the version number constitutes a new
>release
>> > and
>> > > carries the implicit promise that the package works again.  This
>is why
>> > >
>> >
>> > Here I would respectfully disagree.  Code in the devel branch
>carries no
>> > guarantees.
>> > I think we have been pretty loose with respect to package version
>number
>> > bumping in devel
>> > branch; the svn tracking can be used to deal with isolation of code
>for
>> > rollbacks.
>> >
>> > In this informal regime the package version number is a simple
>marker of
>> > package state.
>> > I think it has served us pretty well in past years but the
>developer
>> > community was smaller
>> > and had fairly homogeneous habits.
>> >
>> > Clearly there is room for more regimentation in this area but at
>the
>> moment
>> > I agree with
>> > Dan that version numbers are cheap and should be bumped when new
>code is
>> > committed.
>> > And the recognition by all that a devel image may not work and may
>change
>> > fairly dramatically
>> > while in devel should be general; whether we need to alter that is
>open
>> to
>> > question but I would
>> > think not.
>> >
>> >
>> > > continuous integration systems do a build when the version number
>> > changes.
>> > >
>> > > One should expect working software when installing a pre-build
>package
>> > (the
>> > > tests passed, right?).  Checking out from SVN is for developers
>of that
>> > > package and nothing should be assumed about the current state of
>the
>> > code.
>> > >
>> > > To keep everyone happy, one could add a commit hook to our SVN
>setup
>> that
>> > > would add the SVN revision number to the version string.  This
>would be
>> > for
>> > > dev only and hopefully not sufficient to trigger a build.
>> > >
>> > > That's my two cents.  Happy weekend all.
>> > >
>> > > Regards,
>> > >
>> > >
>> > >
>> > > Pete
>> > >
>> > > ____________________
>> > > Peter M. Haverty, Ph.D.
>> > > Genentech, Inc.
>> > > phaverty at gene.com
>> > >
>> > >
>> > > On Fri, Sep 5, 2014 at 4:30 PM, Dan Tenenbaum
><dtenenba at fhcrc.org>
>> > wrote:
>> > >
>> > > >
>> > > >
>> > > > ----- Original Message -----
>> > > > > From: "Stephanie M. Gogarten" <sdmorris at u.washington.edu>
>> > > > > To: "Dan Tenenbaum" <dtenenba at fhcrc.org>, "bioc-devel" <
>> > > > bioc-devel at r-project.org>
>> > > > > Sent: Friday, September 5, 2014 4:27:13 PM
>> > > > > Subject: Re: [Bioc-devel] Please bump version number when
>> committing
>> > > > changes
>> > > > >
>> > > > > I am guilty of doing this today, but I have (I think) a good
>> reason.
>> > > > > I'm making a bunch of changes that are all related to each
>other,
>> but
>> > > > > are being implemented and tested in stages.  I'd like to use
>svn to
>> > > > > commit when I've made a set of changes that works, so I can
>roll
>> back
>> > > > > if
>> > > > > I break something in the next step, but I'd like the users to
>see
>> > > > > them
>> > > > > all at once as a single version update.  Perhaps others are
>doing
>> > > > > something similar?
>> > > > >
>> > > >
>> > > > I understand the motivation but this still results in an
>ambiguous
>> > state
>> > > > if two different people check out your package from svn at
>different
>> > > times
>> > > > today (before and after your changes).
>> > > >
>> > > > Version numbers are cheap, so if version 1.2.3 exists for a day
>> before
>> > > > version 1.2.4 (which contains all the changes you want to push
>to
>> your
>> > > > users) then that's ok, IMO.
>> > > >
>> > > > Including a version bump doesn't impact whether or not you can
>> > rollback a
>> > > > commit with svn.
>> > > >
>> > > > Dan
>> > > >
>> > > >
>> > > >
>> > > > > Stephanie
>> > > > >
>> > > > > On 9/4/14, 12:04 PM, Dan Tenenbaum wrote:
>> > > > > > Hello,
>> > > > > >
>> > > > > > Looking through our svn logs, I see that there are many
>commits
>> > > > > > that are not accompanied by version bumps.
>> > > > > > All svn commits (or, if you are using the git-svn bridge,
>every
>> > > > > > group of commits included in a push) should include a
>version
>> bump
>> > > > > > (that is, incrementing the "z" segment of the x.y.z version
>> > > > > > number). This practice is documented at
>> > > > > >
>http://www.bioconductor.org/developers/how-to/version-numbering/
>> .
>> > > > > >
>> > > > > > Failure to bump the version has two consequences:
>> > > > > >
>> > > > > > 1) Your changes will not propagate to our package
>repository or
>> web
>> > > > > > site, so users installing your package via biocLite() will
>not
>> > > > > > receive the latest changes unless you bump the version.
>> > > > > >
>> > > > > > 2) Users *can* always get the current files of your package
>using
>> > > > > > Subversion, but if you've made changes without bumping the
>> version
>> > > > > > number, it can be difficult to troubleshoot problems. If
>two
>> > > > > > people are looking at what appears to be the same version
>of a
>> > > > > > package, but it's behaving differently, it can be really
>> > > > > > frustrating to realize that the packages actually differ
>(but not
>> > > > > > by version number).
>> > > > > >
>> > > > > > So if you're not already, please get in the habit of
>bumping the
>> > > > > > version number with each set of changes you commit.
>> > > > > >
>> > > > > > Let us know on bioc-devel if you have any questions about
>this.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Dan
>> > > > > >
>> > > > > > _______________________________________________
>> > > > > > Bioc-devel at r-project.org mailing list
>> > > > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > > > > >
>> > > > >
>> > > >
>> > > > _______________________________________________
>> > > > Bioc-devel at r-project.org mailing list
>> > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > > >
>> > >
>> > >         [[alternative HTML version deleted]]
>> > >
>> > > _______________________________________________
>> > > Bioc-devel at r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > >
>> >
>> >         [[alternative HTML version deleted]]
>> >
>> > _______________________________________________
>> > Bioc-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>	[[alternative HTML version deleted]]
>
>_______________________________________________
>Bioc-devel at r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/bioc-devel

	[[alternative HTML version deleted]]

More information about the Bioc-devel mailing list