Re: [Jmol-developers] Tag Jmol releases

[Spencer B. <spe...@gm...>]

I'm not seeing any technical problems with the current non-semantic version
<http://semver.org/> 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 regarding SNAPSHOT builds would work, but it would mean
that maven always lags one version behind sourceforge. Plus, SNAPSHOT
builds are really intended to be auto-built from trunk. I'm not entirely
sure how Jmol development is currently organized (does trunk correspond to
the 14.7 line?), but it feels like things that are good enough for sf
should be full releases.

On Tue, Aug 30, 2016 at 10:22 AM, Nicolas Vervelle <nve...@gm...>
wrote:

>
>
> On Tue, Aug 30, 2016 at 10:16 AM, Spencer Bliven <spe...@gm...
> > 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 previous
>> jar without giving it a new version number, so we can't just have a
>> "14.6.2" branch that will get updated every week.
>>
>
> I thought that not using the maven standard version numbering (x.y.z)
> would make things more difficult for using the artifact. Is it not ?
> Maybe using the SNAPSHOT releases until a version is completely finalized
> ? (for example, only 14.6.2-SNAPSHOT releases until there's a higher
> version number, and then 14.6.2 release is the last in the 14.6.2-SNAPSHOT)
>
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> Jmol-developers mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>