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
