devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <r...@apache.org>
Subject Re: [DISCUSS] SVN, versioning, and namespace
Date Mon, 20 Apr 2015 18:51:06 GMT
Hi,

LGTM. +1.

Cheers,
Radu

On Mon, 20 Apr 2015 at 21:06 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.
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message