Re: What branch to do OSGi R-next work in.

2017-01-07 Thread Carsten Ziegeler
Thomas Watson wrote > I went ahead and placed my updates for the OSGi R7 resolver v1.1 > specification in osgi-r7/resolver. Thanks for the tip on svn cp. > I moved configadmin, scr and configurator to that dir as well Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org

Re: What branch to do OSGi R-next work in.

2017-01-06 Thread Thomas Watson
I went ahead and placed my updates for the OSGi R7 resolver v1.1 specification in osgi-r7/resolver. Thanks for the tip on svn cp. Tom On Thu, Jan 5, 2017 at 10:46 AM, Carsten Ziegeler wrote: > Thomas Watson wrote > > I'm fine with this approach, but I do wonder what the history of the > files

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Carsten Ziegeler
Thomas Watson wrote > I'm fine with this approach, but I do wonder what the history of the files > will look like after all this copying around of source code. It would be > nice if the history of the files contained in the release folders (i.e. > trunk/scr) maintained the proper history so we can

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Thomas Watson
I'm fine with this approach, but I do wonder what the history of the files will look like after all this copying around of source code. It would be nice if the history of the files contained in the release folders (i.e. trunk/scr) maintained the proper history so we can lookup what revision change

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Carsten Ziegeler
Felix Meschberger wrote > >> >> What about renaming scr to scr-r7-branch and scr-2.0.x to scr and the >> same for config admin but leaving them in trunk? >> Or creating and osgi-r7 directory in trunk and move the stuff there? > > I like the folder, because it then properly delineates all the OSGI

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Felix Meschberger
Hi > Am 05.01.2017 um 17:06 schrieb Carsten Ziegeler : > > Felix Meschberger wrote >> Hmm, this sounds confusing somehow… >> >> why not have: >> >> felix/trunk/configadmin — releasable R6 based Config Admin >> felix/trunk/scr — releasable R6 based DS >> felix/branches/osgi-r7/configadmin

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Carsten Ziegeler
Felix Meschberger wrote > Hmm, this sounds confusing somehow… > > why not have: > >felix/trunk/configadmin — releasable R6 based Config Admin >felix/trunk/scr — releasable R6 based DS >felix/branches/osgi-r7/configadmin — un-releasable R7 work on Config Admin >felix/branches/osgi-

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Felix Meschberger
> Carsten >>> >>> Thomas Watson wrote >>>> Changed subject to stop hijacking the discussion on releasing provisional >>>> API from the org.osgi namespace. >>>> >>>> How do we come to an agreement on what branch to d

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Carsten Ziegeler
gt; wrote: > >> I assume you're talking about DS, right? >> >> I'll create a branch similar to what we did for config admin >> >> Carsten >> >> Thomas Watson wrote >>> Changed subject to stop hijacking the discussion on releasing provisi

Re: What branch to do OSGi R-next work in.

2017-01-05 Thread Thomas Watson
arsten > > Thomas Watson wrote > > Changed subject to stop hijacking the discussion on releasing provisional > > API from the org.osgi namespace. > > > > How do we come to an agreement on what branch to do OSGi R-next work > in? I > > would prefer

Re: What branch to do OSGi R-next work in.

2017-01-04 Thread Carsten Ziegeler
ment on what branch to do OSGi R-next work in? I > would prefer to keep trunk in a releasable state based on the latest > published specification from OSGi. But we have more and more R7 work now > going on directly in trunk. Is it past the point of no return? > > Tom. > &g

What branch to do OSGi R-next work in.

2017-01-04 Thread Thomas Watson
Changed subject to stop hijacking the discussion on releasing provisional API from the org.osgi namespace. How do we come to an agreement on what branch to do OSGi R-next work in? I would prefer to keep trunk in a releasable state based on the latest published specification from OSGi. But we