Re: [Jmol-developers] Tag Jmol releases
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 <nverve...@gmail.com> 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
Re: [Jmol-developers] Tag Jmol releases
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 <hans...@stolaf.edu> 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 <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 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 <hans...@stolaf.edu> >> 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
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 <hans...@stolaf.edu> 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
Re: [Jmol-developers] "color darkgrey" is rejected
I recommend a new 'colour' command to handle the greys ;) On Sat, Sep 3, 2016 at 4:38 AM, Robert Hansonwrote: > of course, we could just not use "darkgrey" > > On Fri, Sep 2, 2016 at 2:08 PM, Angel Herráez > wrote: > >> Bob, >> I know you worked on this recently. >> I am testing this on "14.6.2_2016.08.28 2016-08-28 07:48" >> >> color gray >> color grey >> color lightgray >> color lightgrey >> color darkgray // all ok up to here >> color darkgrey // script ERROR: a color or palette name (Jmol, Rasmol) is >> required >> >> >> >> >> -- >> ___ >> 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