On 09/08/2014 06:15 AM, Gabe Becker wrote:
Michael,
Tags could work. Another approach would be to update the repository and
then look in the log to see if the version number was changed in the most
recent commit. In a sense this is the converse of what our GRANBase package
does when locating historical package versions within the Bioc SVN.
This has the benefit of not requiring the authors do anything they didn't
already need to do in order to "flag" a release (i.e., bump the version
number).
I should note also to Dan's later point that while the Bioc repository
always builds whatever is in the latest commit currently, that need not be
the case. Our internal package repository only builds on version bumps (of
a package or any of it's recursive dependencies).
In hopes of closure...
1. The original motivation and primary message is that a version bump is
required for your commits to propagate to biocLite. Developers often forget to
bump versions. So please always bump versions.
2. A secondary message is that it is confusing to have two (or more) variants of
a package represented by the same version number. Since Bioconductor packages do
not include a reference to the svn revision, this should severely temper any
system of conditional version bumps. This is reinforced by the nearly unlimited
availability of version numbers, the build system requirement that the package
at least build and check successfully before being pushed, diligent application
of unit tests and test-driven development (;)), and that commits are to the
'devel' branch where there is some tolerance of broken functionality. So please
invoke exceptions to 1 only after very careful consideration.
Several valid points came up during the thread. SVN is certainly less flexible
than git when dealing with branches (and the way our svn repository and
permissions are structured makes it particularly difficult to commit to a
non-trunk or release branch). Our build system does have idiosyncratic features
(e.g., nightly builds of all packages; build from svn regardless of version
bump; pushing to a public repository on version bump and successful build) that
conflate version control with software 'release'; these reflect both policy and
software implementation decisions, both of which could be changed [there are no
immediate plans to do so]. It is better to understand the current system and
limitations than to interact with our svn and build system as though they were
git and implemented CI.
Personally, I have rarely intentionally committed user-visible changes to svn
without a version bump (hard to say that with an entirely straight face). I'll
admit to having made temporary strictly local git repositories while I explore
alternative implementations. The primary scenario that gives me pause is
committing code that I know to be functional but incorrect; I would not expose
this as part of the user API (e.g., using a function that is not exported from
the name space) and recognize that in this case svn and the build system are
working against rather than with me.
Martin
~
G
On Fri, Sep 5, 2014 at 6:48 PM, Michael Lawrence <lawrence.mich...@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 <st...@channing.harvard.edu>
wrote:
On Fri, Sep 5, 2014 at 7:50 PM, Peter Haverty <haverty.pe...@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.
phave...@gene.com
On Fri, Sep 5, 2014 at 4:30 PM, Dan Tenenbaum <dtene...@fhcrc.org>
wrote:
----- Original Message -----
From: "Stephanie M. Gogarten" <sdmor...@u.washington.edu>
To: "Dan Tenenbaum" <dtene...@fhcrc.org>, "bioc-devel" <
bioc-devel@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
