Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@devicemap.apache.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAKuYhJsgDHwMH_8pC-Csq_wzLvOZMiSuLyLvxx-OGthvFVAQgg@mail.gmail.com>
References: 
 <CAKuYhJuOh3f3KHT9ELaurwDcS2FZWSZju=6Zuoi9jTh8LVZQqQ@mail.gmail.com>
	<CAKuYhJsgDHwMH_8pC-Csq_wzLvOZMiSuLyLvxx-OGthvFVAQgg@mail.gmail.com>
Date: Mon, 20 Apr 2015 21:19:59 +0200
Message-ID: 
 <CAAGawe3O+pLJxJH1M5PKRSns=2nQNCr77VUmcwmxn_0OOa9wkQ@mail.gmail.com>
Subject: Re: [DISCUSS] SVN, versioning, and namespace
From: Werner Keil <werner.keil@gmail.com>
To: dev@devicemap.apache.org
Content-Type: multipart/alternative; boundary=001a113d1cece62f5805142cd01f

--001a113d1cece62f5805142cd01f
Content-Type: text/plain; charset=UTF-8

Yes,

Though they were not released there are nevertheless a number of examples.
All currently under the "org.apache.devicemap.examples" namespace (which is
what many projects do, Sling or DeltaSpike included)
At leasts the 2 instances running on URLs like
http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
projects.

Whether  or not there was a different structure, since they were not
officially released yet, we seem free. I don't see great harm in the
/tags/examples tag as mentioned. It marks a stable RC1 snapshot of what
could become a joint "examples-1.0.0" release. Unless we prefer to further
disect them, but that does not make a 1.0-RC1 worthless. It matches what
runs on the VM for example;-)

With few exceptions btw, the 0.x version space was for incubating projects.
Hence and since others like Browsermap (or the W3C impl) had a longer
history some version numbers were already higher before graduation.

Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or Tamaya
sounds worth exploring.
This would be an area for 0.x kind of artifacts. And "playground". I am not
sure, if it was a good idea to have an entire branch for that, but open to
ideas.
Earlier efforts like the Sling demo Radu worked on some while ago could be
good in such "sandbox" (at JavaMoney we called it "shelter" inspired by the
"Adopt-a-JSR" program and there's been some great progress in such a
sandbox, e.g. Groovy support, Digital Currencies, etc.)

Werner

On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <rezan@apache.org> wrote:

> Also, as far as I am aware, we only have 4 officially released artifacts:
>
> -data
> -java client
> -.NET client (its not on the website but im certain we did a VOTE)
> -browsermap (javascript) client
>
> All artifacts are all versioned in 1.x.
>
> On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <rezan@apache.org> wrote:
>
> > Moving this to a clean thread.
> >
> > If we can reach agreement here, I will start a [VOTE] thread with all the
> > details listed out and upon a successful vote, we will implement said
> > details (and enforce them moving forward).
> >
> > Feel free to add any points you think are relevant. As always, refrain
> > from using names, just technology and practices.
> >
> >
> > On Mon, Apr 20, 2015 at 1:30 PM, Reza Naghibi <rezan@apache.org> wrote:
> >
> >> Bertrand, PMC members, et al,
> >>
> >> So I had a few out of thread conversations with people and it turns out
> a
> >> these people are very committed to DeviceMap and by leaving this
> project I
> >> would be kind of letting them down. This was never my intention and so
> Im
> >> willing to take Bertrands offer and apply some kind of code partition
> >> policy.
> >>
> >> So here is what I would be willing to work with. I will explain the
> >> standard SVN layout with an addition to accommodate the ODDR branch:
> >>
> >> https://svn.apache.org/viewvc/devicemap/
> >>
> >> *tags* - this folder is for Apache DeviceMap released snapshots and is
> >> obviously used for archiving and branch sourcing purposes. Any software
> >> that is unreleased under Apache rules will be cleared out.
> >>
> >> *branch* - this folder is open to anyone to work on new releases or
> >> experimental features. Just make sure to put your code in a proper sub
> >> directory.
> >>
> >> *trunk* - this folder is only for development of currently released
> >> software. If said software is unreleased, then it needs to go into
> branch
> >> or the ODDR folder. *This will require significant cleanup since we have
> >> the marriage of 1.x and ODDR in here. I repeat, unreleased code and
> their
> >> dependencies, specifically ODDR will be moved into
> >> their appropriate folders.* When we release a major version, the release
> >> branch and move to trunk and the prior major version will switch to
> branch
> >> (and tags will be made). This way we can support old and new but trunk
> will
> >> always be our release head.
> >>
> >> *oddr* - we need a separate repo to house ODDR artifacts. Adding a
> >> folder to our SVN root should be enough to accommodate ODDR dev.
> >>
> >> The other request I have is agreement on an ODDR name space and
> version. *Had
> >> I anticipated this situation, our 1.x release would be 2.x, the proposed
> >> 2.x would be 3.x, and ODDR could hold the 1.x version. This was a
> mistake
> >> and that ship has sailed.* My concern is that I dont want currently
> >> released software to be up-revved in repositories and cause package
> >> confusion since we are all sharing the DeviceMap name space. So we need
> to
> >> properly name and version ODDR so if it does get released and
> maintained,
> >> it can be done without causing confusion with regard to the 1.x, 2.x,
> 3.x
> >> release path we seem to be going down. I would be willing to give ODDR
> the
> >> 0.x version space since thats a pretty standard practice. Im open to
> ideas
> >> here.
> >>
> >> Since we dont really have the ability for grainular folder access, I
> >> think we have to ask that if you did not create or work on a particular
> >> code base, ask permission before committing otherwise you can expect
> your
> >> code to be reverted by the maintainers.
> >>
> >> Finally, any sort of marketing or presentations must clearly state the
> >> product (codebase) and version as to not cause product and version
> >> confusion.
> >>
> >> If we can all come to agreement here and then implement the SVN changes,
> >> then I would feel very comfortable that we can move this project
> forward in
> >> a more partitioned fashion.
> >>
> >>
>

--001a113d1cece62f5805142cd01f--