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-r7/scr — un-releasable R7 work on DS … and this can be continued for other projects where we work on for R7 implementations such as the Configurator etc. Drawback is, that this is somehow „hidden“ in a different, yet SVN custom, branch tree. Regards Felix > Am 05.01.2017 um 16:16 schrieb Carsten Ziegeler <[email protected]>: > > In trunk we have now > configadmin-1.8.x (R6) > configadmin (R7) > scr-2.0.x (R6) > scr (R7) > > So we can release config admin at any time from the 1.8.x directory and > scr from the scr-2.0.x. > > I'm fine with adding a readme, however as we have the voting period we > will catch such a release anyway before it will become public. > > Carsten > > Thomas Watson wrote >> What branch is that for config admin? Can you point me to it? Is this a >> branch to do releases out of while trunk is in a state that cannot be >> released? >> >> I don't mind this process, but I think it should be made clear in trunk >> that the ongoing work there cannot be released. Perhaps with a readme file >> or something in the project that points to the branch where releases can be >> done from? >> >> Tom >> >> On Wed, Jan 4, 2017 at 11:52 PM, Carsten Ziegeler <[email protected]> >> 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 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 have more and more R7 work now >>>> going on directly in trunk. Is it past the point of no return? >>>> >>>> Tom. >>>> >>>> >>>> On Wed, Jan 4, 2017 at 8:33 AM, Felix Meschberger <[email protected]> >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> As of now, we don’t have an official branch policy. In fact we had a >>>>> discussion before and we decided against such. >>>>> >>>>> So I would think that we should continue releasing from trunk and from >>>>> trunk only. >>>>> >>>>> As such I like Tom’s proposal for a R-Next working branch. And since >>> OSGi >>>>> generally releases yearly with just consecutive spec version numbers we >>>>> could just create a single branches/osgi-r-7 (or 8 or 9 or …) branch >>> where >>>>> we have branch copies of the specs we implement. >>>>> >>>>> This is orthogonal, though, to the question of whether we should be >>>>> „releasing“ provisional API in the org.osgi namespace. >>>>> >>>>> Regards >>>>> Felix >>>>> >>>>>> Am 04.01.2017 um 15:23 schrieb Thomas Watson <[email protected]>: >>>>>> >>>>>> My preference would be to do new osgi R-Next work in a dedicated >>> feature >>>>>> branch instead of directly in trunk. That way trunk remains releasable >>>>> at >>>>>> all times. But if we want to instead branch each project when its >>> trunk >>>>>> version becomes unreleasable then I guess that is fine, but it does >>> seem >>>>>> confusing. >>>>>> >>>>>> If that is what felix dev has agreed to then I do request a branch for >>>>> scr >>>>>> to release some fixes for the R6 scr implementation. I'm have a few >>>>> fixes >>>>>> that I need to get released very soon in order to allow the felix scr >>>>>> implementation to be used as the DS implementation in Eclipse. >>>>>> >>>>>> Tom >>>>>> >>>>>> On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler <[email protected] >>>> >>>>>> wrote: >>>>>> >>>>>>> Thomas Watson wrote >>>>>>>> This has come to my attention because I am working on some fixes in >>> the >>>>>>> SCR >>>>>>>> implementation. I noticed the latest SCR in trunk now depends on >>>>>>>> org.apache.felix.configadmin 1.9.0-SNAPSHOT. And I think >>>>>>>> org.apache.felix.configadmin 1.9.0 is being used to implement OSGi >>> R7. >>>>>>> So >>>>>>>> now we have OSGi R7 API updates in trunk for existing OSGi packages. >>>>> If >>>>>>> I >>>>>>>> understand correctly that means trunk is no longer in a state where >>> we >>>>>>> can >>>>>>>> release SCR or configadmin out of. Instead we have to create a >>> branch >>>>> to >>>>>>>> get new releases of these bundles until a time when OSGi R7 is >>>>> finalized >>>>>>>> and released. That seems like a bad state to be in. >>>>>>>> >>>>>>> >>>>>>> We already have the branch for config admin and if we think that we >>> need >>>>>>> another R6 based release of SCR we can create the branch on demand >>> like >>>>>>> we did with config admin. >>>>>>> I started with these two projects in a branch and at one point we have >>>>>>> to merge the branch into trunk. I thought that now is the time as I >>>>>>> didn't expect another release before R7 will be out. Might be wrong... >>>>>>> In any case, creating that branch is easy. Just shout and it will be >>>>> done. >>>>>>> >>>>>>> Carsten >>>>>>> >>>>>>> -- >>>>>>> Carsten Ziegeler >>>>>>> Adobe Research Switzerland >>>>>>> [email protected] >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >>> >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
