Hi! As far as I understand your message you have two levels of versioning. Maven has the concept of releases and snapshots. So, when you release a new version of the CSL from time to time and you create a branch (or tag) in the style repository, there should also be a new release to Maven central with a version number such as 1.0, 1.1, or whatever. Snapshots, however, can be based on the master branch and can be uploaded daily or weekly or something like that. Please have a look here for a description how snapshots work: http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it
As you can see a snapshot's version number is usually the next release version plus "-SNAPSHOT". Of course, snapshots are volatile and can be changed at any time (even the name/version can change). However, the good thing about this is that users have access to the latest updates in the master branch almost immediately through snapshots and if they need something more stable they will have the releases. I've done a little research and it seems you don't have to GPG sign shapshots when you upload them to Maven Central. This means that we can install something like Jenkins/Hudson to automate publishing snapshots every night or every week or so (we should agree on something). I can do this on my server if you like. A Git hook still won't work because you need the user credentials saved somewhere. What do you think? Releases plus snapshots? What versioning scheme would you prefer for both of them? Cheers, Michel Am 10.09.2013 20:28, schrieb Rintze Zelle: > On Tue, Sep 10, 2013 at 2:14 PM, Michel Krämer <[email protected]> wrote: >>> repository is ever-evolving, and your downstream users might expect >>> changes to the GitHub styles repo to end up in Maven in a timely >>> manner. How do you envision this? >> You usually only publish releases to Maven Central. There's a special >> area for snapshots that can be uploaded on a day-to-day basis or every >> week or so, but AFAIK they will be deleted after some time (I'm not >> quite sure about this). >> >> I will try to upload changes from time to time, but I would suggest to >> think about a better versioning scheme, because once an artifact is >> released under a specific version it should not be changed anymore >> (unless you want to break clients that use it). Something like >> 1.0.1.DATE (i.e. 1.0.1.20130910) would work, for example. But I guess it >> would be better to create "real" releases from time to time (1.1, 1.2, >> 2.0, etc.). > > Just some background: we currently always validate the "master" branch > of the style repository against the latest release of the CSL schema. > Upon a new release, we create a new branch for the previous version > (e.g. I created a "1.0" branch when we released CSL 1.0.1), and update > styles in the "master" branch as necessary to validate against the new > schema. In practice, we only ever get contributions for the "master" > branch. > > To avoid confusion among your users, I'd strongly suggest avoiding a > versioning scheme that looks like a CSL version number, but isn't one > (as would be the case with a "1.1", "1.2", ... scheme). I like the > 1.0.1.DATE much better. > > Rintze > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
