Well if we did then the /data "1.0.0" tags I placed initially could/should
also be either copied or moved.
As mentioned, there is no archive for "test-data-1.0.0" but I tagged it
together with the main data to avoid a separate ${devicemap.data} property
in projects using either or both data artifacts (several web applications
and DDR Simple do) If those should be MOVED then without an official
candidate archive test-data may need to be considered "candidate" for now,
I'd probably rename its tag to something like "1.0.0-RC1" then. Otherwise
could somebody also create an archive for those?Other "candidate" tags that look fine there are e.g. all OpenDDR sync points. They ensure that apps using a particular version of OpenDDR now could migrate to a matching version of DeviceMap if they want exactly the same data content and consistency. As soon as 1.0.0 is out, they may of course prefer that, but it depends on what apps exist. Each of these OpenDDR sync tags can be seen more or less as drop-in replacements for the OpenDDR eqivalent. Werner On Thu, Jul 17, 2014 at 12:00 PM, Bertrand Delacretaz < [email protected]> wrote: > On Thu, Jul 17, 2014 at 11:54 AM, Werner Keil <[email protected]> > wrote: > > > ...I find it extremely useful to collect official release tags (in SVN > > that's just a second pointer, it normally won't waste much space, > > especially for source files) as Bertrand suggested > > http://svn.apache.org/viewvc/incubator/devicemap/tags/releases/ > > <http://svn.apache.org/viewvc/incubator/devicemap/tags/> > > > > Yes that's where I suggest putting tags for releases, with no subfolders, > like Reza did for two tags that are there. > > Release candidate tags are probably fine there as well IMO if identified, > with a .rcN suffix for example. They can then be renamed when the release > candidate is promoted to an actual release. > > -Bertrand >
