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 <[email protected]> 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 <[email protected]> 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. >> >>
