Thanks Colm and Emmanuel for the thoughts and help! >>The numering scheme we use for ApacheDS is a bit complex and its history is >>long... The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
>> I would suggest you cut a 1.0-RC1 when you feel like ready, and after one or >> two iteration, when some obvious bugs have been fixed, go for a final 1.0.0 >> version. After that, better moving to a 2.0.0 quickly than starting with >> 2.1, 2.1.1, etc. A la Chrome/Firefox... The way is great. +1 totally. Thanks! >> Keep in mind that we release sources ! Now, you can also build some >> convenient packages, but this will be a side product. I see. So as Colm explained, maybe we could have some container modules for such convenient packages? >> I can definitively give a hand, as I have been releasing most of the other >> projects for years now... This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following. So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?). I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go? Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Thursday, June 04, 2015 12:31 AM To: [email protected] Subject: Re: Kerby release Le 03/06/15 16:41, Colm O hEigeartaigh a écrit : > Hi Kai, > > Answers inline. > >> 1. What version would we have for the release, some options from my >> view: 1.0, 0.1, or 1.0-M1 and so on. I saw we just released Apache >> Directory Server 2.0.0-M20, would Kerby project follow this style or >> otherwise? M20 looks too long for a major release IMHO. >> > It's just a matter of personal preference I suppose. If it were up to > me, I would call it 1.0.0, or possibly 1.0.0-M1 if you feel that it is > not usable in production yet. The numering scheme we use for ApacheDS is a bit complex and its history is long... We released ApacheDS 1.0 a long time ago (almost 10 years), then we decided stupidely to switch to 1.5, as Tomcat did with tomcat-5.5 : basically, we also switched to Java 5, and decided that it should reflect in the numering, thus the 1.5. Obviously, this was a mistake, as we advertized it as non stable ! (X.0 were supposed to be stable, X.5 were supposed to be unstable. Go fish...). At some point, we decided to stop with this non-sense, and to switch to milestones. The next version after 1.5.7 was 2.0.0-M1. We weren't expecting having that many mailstones, but at some point, we always had something critical to fix, and we kept going with new milestones. One of the reasons was that we knew that once we go to a final 2.0, we will have to provide some tooling to migrate from 2.x to 2.x+1, and we were not ready for that. There is no reason to have that many milstones with kerby. I would suggest you cut a 1.0-RC1 when you feel like ready, and after one or two iteration, when some obvious bugs have been fixed, go for a final 1.0.0 version. After that, better moving to a 2.0.0 quickly than starting with 2.1, 2.1.1, etc. A la Chrome/Firefox... > >> 2. What’s the artifacts we would have for the release? How about: >> >> 1) JARs (to be published): Client side Kerberos library in a jar; >> KDC side Kerberos library in a jar; Kerby facilities (Netty, LDAP, >> Zookeeper backends and so on) in a jar >> > We will just use Maven to drive the release process. Normally, for > projects at Apache it's just a matter of "mvn release:prepare; mvn > release:perform". > This takes care of tagging the release, signing the jars, and > uploading them to repository.apache.org, where you "close" them and > get it ready for a vote. Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product. >> 3. Would anyone take and help with the release? >> > I can help out, but not "take" the release as such :-) I can definitively give a hand, as I have been releasing most of the other projects for years now...
