Btw. the Wave project. als incubating pretty much followed a similar pattern. It started with some "wave-0.x-rcy" tags, but the latest tag simply goes "0.4-rc4". At least for further development it would be good to have more tags, also on the .NET artifacts. Thus, if anything may not go into 1.0.0 right now, please consider another tag on a regular basis for significant changes.
Wave has a very nice website, probably something to keep an eye on, as most of ours still says "Now in 2012"[?] As of now I tagged a matching combination of 0.1 "web" and "java" artifacts, so the relative structure would be nice to persist if you tag all of "java" or "csharp". Otherwise it is worth considering a prefix like "client-1.0.0" under the /devicemap tags, or the pattern only for the client artifacts like "devicemap-client-java-1.0.0" we already see in Reza's site. Squashing all artifacts into a single /tags/1.0.0/ folder would totally break the structure they have under /trunk. We have a very sophisticated SVN system over here at my client,, and the SVN admin is keen to keep it merge-able, as he's the one who has to do that if the need arises. Werner On Thu, Jul 10, 2014 at 2:37 AM, Werner Keil <[email protected]> wrote: > Hi, > > I tagged the devicemap-data content after getting version and other > meta-data corrected: > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0 > > The structure underneath is like the latest "openddr" tags, so in theory > we may add "test-data" to it if it still applies, otherwise to another > release. > Have a look at how you want to tag the > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap > subtree. > > Either using the "java" and other folders or putting all of them under a > common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before > the 1.0.0. > > Werner > > On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <[email protected]> > wrote: > >> SVN tags here >> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap >> >> The name space is up to how we want to do this underneath each >> "component" (hence the suggestion someone who can do this in JIRA might add >> actual components for "Java", ".NET" or VB/CSharp and "Data", so far only >> Bertrand and for some credentials like change assigneee Reza are in the >> right group/role) >> >> "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27, >> but as we plan to draft a 1.0.0 milestone release, that can be done via the >> release tag anyway. >> So I'd do this for >> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0 >> >> Ideally all other tags should be similar. The naming convention is >> totally different for every single Apache project. >> >> For a "flat" structure using only the top-level "tags" folder, many >> projects chose something like /tags/devicemap-data-1.0.0. >> >> If you prefer, let's do that for ALL artifacts like that, otherwise just >> "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple >> "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there >> is no mandatory pattern by Apache Foundation, only a common agreement >> inside each team it seems... >> >> If we use the >> /tags/data >> /tags/devicemap >> >> structure, then either >> /tags/devicemap/java-1.0.0 >> /tags/devicemap/csharp-1.0.0 >> ... >> would work or >> /tags/devicemap/java/1.0.0 >> /tags/devicemap/csharp/1.0.0 >> >> I'll leave the decision in the .NET and Java corner to what we like best. >> >> I used "v1.x" under /data/openddr to match the exact same tag OpenDDR >> used in Git. >> No distinct preference here, but for /tags/data will do a simple 1.0.0 >> for now. >> As of now, "test-data" did not seem in the archive, and you did not sound >> too eager to include it with a 1.0.0 release right now, is that correct? >> >> Werner >> >> On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <[email protected]> >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Ooops, lost me there "tagged" ? >>> >>> esjr >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.8 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC >>> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe >>> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB >>> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0 >>> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR >>> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I= >>> =e42w >>> -----END PGP SIGNATURE----- >>> >> >> >
