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

[Peter Haverty]

Hi All,
Git-svn is a nice workaround for the developer. As a user you don't want to be installing from version control in any case. Version control is a means for tracking changes, not for distributing software.   Let the CI system protect you from needless drama.

Typed with thumbs.

> On Sep 5, 2014, at 5:03 PM, "Ryan C. Thompson" <rct at thompsonclan.org> wrote:
> 
> Hi all,
> 
> Just to throw in a suggestion here, I know that many people use a tool like git-svn in this kind of situation. They want the ability to make multiple small commits in order to save their progress, but they don't want those commits visible until they are ready to push all at once. This allows one to make breaking changes in one commit that are fixed by subsequent commits, because the intermediate states will never be exposed.
> 
> For information on git-svn, see here: http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
> 
> Note that I don't personally have any experience with svn or with git-svn, but this seems like exactly the use case for it.
> 
> -Ryan
> 
>> On Fri 05 Sep 2014 04:50:49 PM PDT, Peter Haverty 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
>> 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