btw, shouldn't we cleanup the no longer used goals such as the Felix karaf goals and 1.x?
On Mon, Jan 3, 2011 at 5:20 PM, Andreas Pieber <[email protected]> wrote: > +1 to 2.1.x for the moment with the option that we setup hudson on > (e.g.) 2.0.x the moment the next bugfix/improvement hits this branch. > > kind regards, > andreas > > On Mon, Jan 3, 2011 at 4:11 PM, Guillaume Nodet <[email protected]> wrote: >> Nô, i don't think we need it. >> >> On Monday, January 3, 2011, Jamie G. <[email protected]> wrote: >>> We have a Hudson job for Karaf 2.1.x branch now: >>> https://hudson.apache.org/hudson/job/Karaf-2.1.x/ >>> >>> Do we need to make one for the 2.0.x branch as well? I don't think any >>> active development is happening on that branch right now. >>> >>> Cheers, >>> Jamie >>> >>> On Mon, Jan 3, 2011 at 10:50 AM, Jamie G. <[email protected]> wrote: >>>> We already have trunk on hudson: >>>> https://hudson.apache.org/hudson/job/Karaf/ >>>> >>>> Will have to see whom is familiar here with getting the branches added >>>> to Hudson as well. >>>> >>>> Cheers, >>>> Jamie >>>> >>>> On Mon, Jan 3, 2011 at 9:46 AM, Andreas Pieber <[email protected]> wrote: >>>>> Good, this means according to [1] that some PMC has to setup the >>>>> hudson build (or give me the required permissions to do it myself :)). >>>>> >>>>> kind regards, >>>>> andreas >>>>> >>>>> [1] http://wiki.apache.org/general/Hudson >>>>> >>>>> On Mon, Jan 3, 2011 at 2:11 PM, Jamie G. <[email protected]> wrote: >>>>>> That sounds like a good idea for the snapshot builds :) >>>>>> >>>>>> On Mon, Jan 3, 2011 at 9:28 AM, Andreas Pieber <[email protected]> >>>>>> wrote: >>>>>>> Basically I've no problems with that; but I think we really should >>>>>>> provide hudson builds (and automate deploys to apache-snapshot repos) >>>>>>> for all supported branches, don't you think? >>>>>>> >>>>>>> kind regards, >>>>>>> andreas >>>>>>> >>>>>>> On Mon, Jan 3, 2011 at 1:51 PM, Jamie G. <[email protected]> >>>>>>> wrote: >>>>>>>> Hi Andreas, >>>>>>>> >>>>>>>> It doesn't appear that we have a written policy for Karaf maintenance. >>>>>>>> In general we reserve trunk for new development, and the patch >>>>>>>> branches for bug fixes (and the rare improvement that does not break >>>>>>>> backwards compatibility). >>>>>>>> >>>>>>>> Right now the current active support is on the 2.1.x branch and main >>>>>>>> trunk. After the 2.2.0 release occurs then we will have the 2.1.x, >>>>>>>> 2.2.x, and the new trunk as active lines. I do not believe we have a >>>>>>>> planned discontinue of support for the earlier releases, if such was >>>>>>>> to be considered I'm sure that we would have an open discussion and >>>>>>>> vote on the matter. Personally, as long as bug fixes are being >>>>>>>> submitted to past branches I'm more than happy to spin up a release >>>>>>>> candidate for consideration & vote. >>>>>>>> >>>>>>>> If anyone else knows better on the subject please help clarify the >>>>>>>> matter :) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jamie >>>>>>>> >>>>>>>> On Thu, Dec 30, 2010 at 3:36 AM, Andreas Pieber <[email protected]> >>>>>>>> wrote: >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> I've seen that there had been a commit to karaf-2.0.x branch; do we >>>>>>>>> still >>>>>>>>> support it? What is the maintenance "policy" for karaf? Which >>>>>>>>> versions do we >>>>>>>>> officially support? Only the latest stable release (e.g. 2.1.x for >>>>>>>>> now)? >>>>>>>>> Where do we "have" to back-port bug-fixes... E.g. if I find a problem >>>>>>>>> in 2.1.2; >>>>>>>>> do I have to also fix it in 2.0.x (if it exists there)? >>>>>>>>> >>>>>>>>> In addition to this question: IMHO we should also setup Hudson build >>>>>>>>> targets for >>>>>>>>> all "officially" supported versions to make bug-fixes easier and >>>>>>>>> faster >>>>>>>>> available via snapshots in the apache snapshot repository. >>>>>>>>> >>>>>>>>> Any ideas? Are there already guidelines documented anywhere? >>>>>>>>> >>>>>>>>> kind regards, >>>>>>>>> andreas >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >
