Re: [Jmol-developers] Tag Jmol releases

2016-08-30 Thread Robert Hanson
The date stamp on the file name is important and effectively constitutes the minor version. Jar files are only updated at SVN on release (as part of tar or zip files). You should only be updating releases. I don't think it will be manageable on my end to create new subminor versions 0.0.n for

Re: [Jmol-developers] Tag Jmol releases

2016-08-30 Thread Nicolas Vervelle
On Tue, Aug 30, 2016 at 4:15 PM, Spencer Bliven wrote: > I'm not seeing any technical problems with the current non-semantic > version numbers. It might make it harder for > downstream users to guess the newest version since numbers aren't >

Re: [Jmol-developers] Tag Jmol releases

2016-08-30 Thread Spencer Bliven
I'm not seeing any technical problems with the current non-semantic version numbers. It might make it harder for downstream users to guess the newest version since numbers aren't sequential (due to the date), but major.minor.patch is just a convention. Your suggestion

Re: [Jmol-developers] Tag Jmol releases

2016-08-30 Thread Nicolas Vervelle
On Tue, Aug 30, 2016 at 10:16 AM, Spencer Bliven wrote: > I would advocate that maven should get a new artifact whenever sourceforge > gets a new jar. For this reason I've been including the date as part of the > version number. There is no way to silently replace a

Re: [Jmol-developers] Tag Jmol releases

2016-08-30 Thread Spencer Bliven
I would advocate that maven should get a new artifact whenever sourceforge gets a new jar. For this reason I've been including the date as part of the version number. There is no way to silently replace a previous jar without giving it a new version number, so we can't just have a "14.6.2" branch