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