New version tag(s) since v1.0

[peterjc]

Currently there is only one version tag on the git repository, v1.0 dated 2015-06-15
https://github.com/thegenemyers/DAZZ_DB/tree/V1.0

I would like to be able to point at a more recent release, for example the 2016-11-11 update which added new tools arrow2DB, DB2arrow and DBwipe.

Are you happy to add a formal version numbering (ideally also accessible via the tools themselves with -v or --version command line switches), or would you recommend referring to particular versions by the date of the associated commit?

In this case, for 2016-11-11 there is only one commit, so this is quite unambiguous:
284e188

[thegenemyers]

Hi Peter, I've not been in the habit of attaching version numbers. My revision "tree" is a straight line, the most recent deposit is the most bug free version of the feature set described on my blog man pages.

…

-- Gene

On 5/30/18, 1:39 PM, Peter Cock wrote: Currently there is only one version tag on the git repository, |v1.0| dated 2015-06-15 https://github.com/thegenemyers/DAZZ_DB/tree/V1.0 I would like to be able to point at a more recent release, for example the 2016-11-11 update which added new tools |arrow2DB|, |DB2arrow| and |DBwipe|. Are you happy to add a formal version numbering (ideally also accessible via the tools themselves with |-v| or |--version| command line switches), or would you recommend referring to particular versions by the date of the associated commit? In this case, for 2016-11-11 there is only one commit, so this is quite unambiguous: 284e188 <284e188> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#34>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGkkNoIJqy7pemIKDq_xwJTG1Xla5WyXks5t3oUIgaJpZM4UTG9z>.

[peterjc]

Thank you for the quick reply. Given you are not in the habit of attaching version numbers, would you agree using dates is a good strategy for people wanting to refer to particular points in the development history (particularly for packaging in contexts like Conda, Homebrew, Linux Distributions, etc)?

(Usually yyyy-mm-dd order as in the ISO date standard for sorting reasons)

[thegenemyers]

Yes, dates should work -- just be careful that its fairly common that after a new update, a number of bugs are reported which are then quickly fixed in follow on pushes. -- Gene

…

On 5/30/18, 2:29 PM, Peter Cock wrote: Thank you for the quick reply. Given you are not in the habit of attaching version numbers, would you agree using dates is a good strategy for people wanting to refer to particular points in the development history (particularly for packaging in contexts like Conda, Homebrew, Linux Distributions, etc)? (Usually yyyy-mm-dd order as in the ISO date standard for sorting reasons) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGkkNo4oeCQH-0s5Apn0usDtE74CXu70ks5t3pC3gaJpZM4UTG9z>.

[peterjc]

Cross reference thegenemyers/DALIGNER#83 and thegenemyers/DALIGNER#2 - @sjackman would a date based versioning scheme for Gene Myers' tools also work for homebrew?

I am thinking something like 1.yyyymmdd or 1.yyyy.mm.dd or 1.yy.mm.dd would be best, these sort after the existing 1.0 release, and leave open the possibility of version 2 using a different scheme should there ever be a wish to move to major.minor.revision or similar.

Paging @rvalieris, @druvus, @daler and @bgruening for input from BioConda.

[sjackman]

@thegenemyers Could we encourage you to please tag a release? It would be very helpful for both package managers and when citing in a paper precisely which version was used.

You can tag versions using the git command line interface or the GitHub web interface https://github.com/thegenemyers/DAZZ_DB/releases/new

[peterjc]

Certainly for use tagged versions would be easier for us (e.g. just tag the current code as v1.1 for DAZZ_DB, DALIGNER, DAMASKER, DEXTRACTOR etc).

But failing that, how about adding something like this to all the README.md files?

Version Numbers

My tools do not use formal major.minor version numbers like
v1.0 or similar. Instead, where a version number is needed - for
example citing the exact revision of the tool used in an analysis,
or for packaging the tool (e.g. in conda, homebrew, a Linux
distribution or similar) - please use v1.yyyy.mm.dd where
yyyy-mm-dd is the date of the final commit used (on the
master branch).

Again, if there is a pre-existing convention about the exact date based format to recommend in one of the big packaging communities, let's recommend that.

[bgruening]

I would also prefer tag releases and release tarballs. If this is not possible lets agree on @peterjc suggestion and fix that after the fact.

[sjackman]

I expected that Semantic Versioning https://semver.org would have a recommendation on using dates, but nope. I'd suggest 1.0.yyyymmdd

[peterjc]

OK, let's go for 1.0.yyyymmdd - that occurred to me after my earlier post as well. This has the advantage of minimal disruption should Gene decide to start using 1.1, 1.2, ... in the near future as everything would sort perfectly as 1.0, 1.0.yyyymmdd (chronological), 1.1, 1.2, ...

So, suggested README.md wording for where the tool does have a v1.0 tag in place:

Version Numbers

v1.0 has been released, but if you need to refer to a later revision
from the stable master branch, please use v1.0.yyyymmdd where
yyyy-mm-dd is the date of the commit used. This is important for
method details in scientific papers, and for software packaging
(e.g. Conda, HomeBrew, or Linux distribution packages).

[peterjc]

See also https://calver.org/ - what we are proposing is a hybrid system, semantic versioning major.minor.revision with an eight digit date as the revision number (yyyymmdd).

[sjackman]

I didn't know about Calver. Thanks for pointing that out.

[thegenemyers]

Dear Shaun, Peter, Bjoern,
My apologies that my somewhat less than professional production of
code is causing issues for you. As I said previously given that the main
branch of every module is a straight line, your proposal to use dates
should be just fine. You all have got me to thinking about this aspect of
the Dazzler suite and I may start using version numbers in the future, but
I wouldn't wait for it :-)
May I ask what y'all are up to -- are you using Dazzler components for
Nanopore data assembly, or, ...?
Cheers, Gene

[peterjc]

Thanks Gene,

No apology needed. Your repositories are very clearly organised with a straightforward commit history, so I think the date based proposal will work just fine (1.0.yyyymmdd with an eight digit date), and this will not stop you adopting traditional version numbers later on (as long as they sort later than this, e.g. 1.1).

Personally my interest is indirect, I want to try out the PacBio assembly tool FALCON, and would like to have it and its dependencies nicely packaged in BioConda.

https://github.com/PacificBiosciences/FALCON
https://github.com/PacificBiosciences/FALCON-integrate

The Pacific Biosciences team have used git-submodules as a way to bundle their dependencies and ensure a specific known compatible version of them is used. This approach makes a lot of sense during development in a fluid system where individual parts change often. However, this is not how Linux distributions, HomeBrew or Conda deal with dependencies, so we'd like to be able to have your tools each nicely packed in their own right - which means we need some way to clearly define the versions.

Thank you for your assistance with this.

(update - fixed a typo)

[thegenemyers]

I've grabbed your note about version numbers and will have it in the header of all future updates to my main branch. Thanks for satisfying my curiosity.

…

-- Gene

On 6/4/18, 11:51 AM, Peter Cock wrote: Thanks Gene, No apology needed. Your repositories are very clearly organised with a straightforward commit history, so I think the date based proposal will work just fine (|1.0.yyyymmdd| with an eight digit date), and this will not stop you adopting traditional version numbers later on (as long as they sort later than this, e.g. |1.1|). Personally my interest is indirect, I want to try out the PacBio assembly tool FALCON, and would like to have it and its dependencies nicely packages in BioConda. https://github.com/PacificBiosciences/FALCON https://github.com/PacificBiosciences/FALCON-integrate The Pacific Biosciences team have used git-submodules as a way to bundle their dependencies and ensure a specific known compatible version of them is used. This approach makes a lot of sense during development in a fluid system where individual parts change often. However, this is not how Linux distributions, HomeBrew or Conda deal with dependencies, so we'd like to be able to have your tools each nicely packed in their own right - which means we need some way to clearly define the versions. Thank you for your assistance with this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGkkNvZHw6U5WeCg8--UJoYf3je1widOks5t5QM0gaJpZM4UTG9z>.