Re: [Jmol-developers] Tag Jmol releases

2016-08-31 Thread Robert Hanson 
All my release notes are in
https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol/src/org/jmol/viewer/Jmol.properties

Can I just add some information that works for you there?


On Wed, Aug 31, 2016 at 4:01 AM, Spencer Bliven 
wrote:

> We should definitely find a solution that doesn't increase the work for
> making a release. One solution that might be easier to automate than SVN
> tags is to include the SVN revision in README-xxx.properties. Then I could
> be sure that I'm checking out the correct revision without adding any more
> steps to the release procedure. I'll look into additional options for
> automating that with ant.
>
> On Tue, Aug 30, 2016 at 8:56 PM, Robert Hanson  wrote:
>
>> 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
>> every check-in. But one thing I could do is release the first dated version
>> without a date if that helps. Just [14.6.3]. Would that somehow help? I'd
>> rather not do that, though.
>>
>> On Tue, Aug 30, 2016 at 3: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 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 would just do a svn copy every time you push something to sourceforge.
>>> Probably there is a way to automate this in ant, but I'd have to look into
>>> it. Manually, something like
>>>
>>> svn copy http://svn.code.sf.net/p/jmol/code/branches/v14_6
>>> http://svn.code.sf.net/p/jmol/code/tags/v14_6_2_2016_08_28
>>>
>>> BTW, I'll be at the Web-based molecular graphics conference next week,
>>> so we can discuss details then if you want.
>>>
>>> -Spencer
>>>
>>> On Mon, Aug 29, 2016 at 7:45 PM, Robert Hanson 
>>> wrote:
>>>
 I would not expect any Maven updates until there is an actual release,
 as I did yesterday. What you are seeing there are minor bug fixes. If I can
 tag those in some way, I'd be happy to do that.

 On Mon, Aug 29, 2016 at 7:42 AM, Spencer Bliven <
 spencer.bli...@gmail.com> wrote:

> Would it be possible to start creating tags for all releases? I think
> the last couple maven releases might have included a few commits more than
> they should have because I just used the head of the 14_6 branch. For
> instance, the "14.6.2_2016.08.28" on maven central was built from r21231.
> I'm not certain whether this matches the revision on sourceforge or 
> whether
> one of the other five commits on 8-28-2016 would have been better. This
> would be much easier to track if the process of releasing to sourceforge
> included a tagging step.
>
> Thanks,
>
> Spencer
>
> 
> --
>
> ___
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>


 --
 Robert M. Hanson
 Larson-Anderson Professor of Chemistry
 St. Olaf College
 Northfield, MN
 http://www.stolaf.edu/people/hansonr


 If nature does not answer first what we want,
 it is better to take what answer we get.

 -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900


 
 --

 ___
 Jmol-developers mailing list
 Jmol-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jmol-developers


>>>
>>> 
>>> --
>>>
>>> ___
>>> Jmol-developers mailing list
>>> Jmol-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>
>>
>> --
>> Robert M. Hanson
>> Larson-Anderson Professor of Chemistry
>> St. Olaf College
>> Northfield, MN
>> http://www.stolaf.edu/people/hansonr
>>
>>
>> If nature does not answer first what we want,
>> it is better to take what answer we get.
>>
>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>
>>
>> 
>> --
>>
>> ___
>> Jmol-developers mailing list
>>

Re: [Jmol-developers] Tag Jmol releases

2016-08-31 Thread Spencer Bliven 
We should definitely find a solution that doesn't increase the work for
making a release. One solution that might be easier to automate than SVN
tags is to include the SVN revision in README-xxx.properties. Then I could
be sure that I'm checking out the correct revision without adding any more
steps to the release procedure. I'll look into additional options for
automating that with ant.

On Tue, Aug 30, 2016 at 8:56 PM, Robert Hanson  wrote:

> 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
> every check-in. But one thing I could do is release the first dated version
> without a date if that helps. Just [14.6.3]. Would that somehow help? I'd
> rather not do that, though.
>
> On Tue, Aug 30, 2016 at 3: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 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 would just do a svn copy every time you push something to sourceforge.
>> Probably there is a way to automate this in ant, but I'd have to look into
>> it. Manually, something like
>>
>> svn copy http://svn.code.sf.net/p/jmol/code/branches/v14_6
>> http://svn.code.sf.net/p/jmol/code/tags/v14_6_2_2016_08_28
>>
>> BTW, I'll be at the Web-based molecular graphics conference next week, so
>> we can discuss details then if you want.
>>
>> -Spencer
>>
>> On Mon, Aug 29, 2016 at 7:45 PM, Robert Hanson 
>> wrote:
>>
>>> I would not expect any Maven updates until there is an actual release,
>>> as I did yesterday. What you are seeing there are minor bug fixes. If I can
>>> tag those in some way, I'd be happy to do that.
>>>
>>> On Mon, Aug 29, 2016 at 7:42 AM, Spencer Bliven <
>>> spencer.bli...@gmail.com> wrote:
>>>
 Would it be possible to start creating tags for all releases? I think
 the last couple maven releases might have included a few commits more than
 they should have because I just used the head of the 14_6 branch. For
 instance, the "14.6.2_2016.08.28" on maven central was built from r21231.
 I'm not certain whether this matches the revision on sourceforge or whether
 one of the other five commits on 8-28-2016 would have been better. This
 would be much easier to track if the process of releasing to sourceforge
 included a tagging step.

 Thanks,

 Spencer

 
 --

 ___
 Jmol-developers mailing list
 Jmol-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jmol-developers


>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Larson-Anderson Professor of Chemistry
>>> St. Olaf College
>>> Northfield, MN
>>> http://www.stolaf.edu/people/hansonr
>>>
>>>
>>> If nature does not answer first what we want,
>>> it is better to take what answer we get.
>>>
>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>>
>>>
>>> 
>>> --
>>>
>>> ___
>>> Jmol-developers mailing list
>>> Jmol-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>
>> 
>> --
>>
>> ___
>> Jmol-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
> 
> --
>
> ___
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
--
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

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
every check-in. But one thing I could do is release the first dated version
without a date if that helps. Just [14.6.3]. Would that somehow help? I'd
rather not do that, though.

On Tue, Aug 30, 2016 at 3: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 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 would just do a svn copy every time you push something to sourceforge.
> Probably there is a way to automate this in ant, but I'd have to look into
> it. Manually, something like
>
> svn copy http://svn.code.sf.net/p/jmol/code/branches/v14_6
> http://svn.code.sf.net/p/jmol/code/tags/v14_6_2_2016_08_28
>
> BTW, I'll be at the Web-based molecular graphics conference next week, so
> we can discuss details then if you want.
>
> -Spencer
>
> On Mon, Aug 29, 2016 at 7:45 PM, Robert Hanson  wrote:
>
>> I would not expect any Maven updates until there is an actual release, as
>> I did yesterday. What you are seeing there are minor bug fixes. If I can
>> tag those in some way, I'd be happy to do that.
>>
>> On Mon, Aug 29, 2016 at 7:42 AM, Spencer Bliven > > wrote:
>>
>>> Would it be possible to start creating tags for all releases? I think
>>> the last couple maven releases might have included a few commits more than
>>> they should have because I just used the head of the 14_6 branch. For
>>> instance, the "14.6.2_2016.08.28" on maven central was built from r21231.
>>> I'm not certain whether this matches the revision on sourceforge or whether
>>> one of the other five commits on 8-28-2016 would have been better. This
>>> would be much easier to track if the process of releasing to sourceforge
>>> included a tagging step.
>>>
>>> Thanks,
>>>
>>> Spencer
>>>
>>> 
>>> --
>>>
>>> ___
>>> Jmol-developers mailing list
>>> Jmol-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>
>>
>> --
>> Robert M. Hanson
>> Larson-Anderson Professor of Chemistry
>> St. Olaf College
>> Northfield, MN
>> http://www.stolaf.edu/people/hansonr
>>
>>
>> If nature does not answer first what we want,
>> it is better to take what answer we get.
>>
>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>
>>
>> 
>> --
>>
>> ___
>> Jmol-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>
>
> 
> --
>
> ___
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

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
> sequential (due to the date), but major.minor.patch is just a convention.
>

To keep numbers in a sequential order, you can use the date in the format
MMDD (and eventually HH24MISS if time also).
At least order will be still easy to follow.



> 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.
>

I haven't followed how Bob is keeping up with the version numbering.
In the old time, there was a stable branch (minor=0, 2, 4, 6, 8...) and a
development (minor=1, 3, 5, 7, 9...), but I'm not sure this distinction is
still there.

Nico


> On Tue, Aug 30, 2016 at 10:22 AM, Nicolas Vervelle 
> wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 10:16 AM, Spencer Bliven <
>> spencer.bli...@gmail.com> 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
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>
>
> 
> --
>
> ___
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
--
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

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 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 
wrote:

>
>
> 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 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
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
--
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

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 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
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

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
that will get updated every week.

I would just do a svn copy every time you push something to sourceforge.
Probably there is a way to automate this in ant, but I'd have to look into
it. Manually, something like

svn copy http://svn.code.sf.net/p/jmol/code/branches/v14_6
http://svn.code.sf.net/p/jmol/code/tags/v14_6_2_2016_08_28

BTW, I'll be at the Web-based molecular graphics conference next week, so
we can discuss details then if you want.

-Spencer

On Mon, Aug 29, 2016 at 7:45 PM, Robert Hanson  wrote:

> I would not expect any Maven updates until there is an actual release, as
> I did yesterday. What you are seeing there are minor bug fixes. If I can
> tag those in some way, I'd be happy to do that.
>
> On Mon, Aug 29, 2016 at 7:42 AM, Spencer Bliven 
> wrote:
>
>> Would it be possible to start creating tags for all releases? I think the
>> last couple maven releases might have included a few commits more than they
>> should have because I just used the head of the 14_6 branch. For instance,
>> the "14.6.2_2016.08.28" on maven central was built from r21231. I'm not
>> certain whether this matches the revision on sourceforge or whether one of
>> the other five commits on 8-28-2016 would have been better. This would be
>> much easier to track if the process of releasing to sourceforge included a
>> tagging step.
>>
>> Thanks,
>>
>> Spencer
>>
>> 
>> --
>>
>> ___
>> Jmol-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
> 
> --
>
> ___
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
--
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers