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] >
