I'm going to create some branches related to the release. 1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK? remotes/origin/cleanssl remotes/origin/dsdev remotes/origin/fixdes remotes/origin/installation remotes/origin/javadoc remotes/origin/kinit remotes/origin/maven-refactor remotes/origin/newlayout remotes/origin/test-enc-message
2. Would have the following branches master branch with necessary clean up: 1) Remove all PKINIT related codes as the feature is still half-baked yet, this will mean to remove the not-yet-commons-ssl library codes; 2) Remove kerby-event related codes as the feature isn't mature yet and we'll get it done in a future major release; 3) Clean up any other problematic codes with double check for the release. pkinit-support branch, to contain the codes for PKINIT feature and we will develop the feature in the branch in future. Will keep synced and well maintained; event-support branch, to contain the codes for the event model support, we will develop the feature in the branch in future. Will keep synced and well maintained. Recently we'll mainly work for the release so the codes should be committed in the master branch directly. When appropriate, we may cut a branch for the 1.0.0-rc1 release based on it. Sounds good to go? Please comment if any concern regarding the process, thanks. Regards, Kai -----Original Message----- From: Zheng, Kai [mailto:[email protected]] Sent: Thursday, June 11, 2015 4:43 PM To: Apache Directory Developers List Subject: RE: Kerby release For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions. I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks. Regards, Kai -----Original Message----- From: Zheng, Kai [mailto:[email protected]] Sent: Thursday, June 04, 2015 8:46 PM To: Apache Directory Developers List Subject: RE: Kerby release Thanks Emmanuel. >> The way to do it is to have special Maven prodiles to build all the packages >> you want. I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way. >>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 >>version for future changes. Is that fine ? Looks perfect to me! >> Atm, what I'd like to have is a release on one of the core Kerby component : >> ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, >> as a separate module. Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Thursday, June 04, 2015 8:17 PM To: Apache Directory Developers List Subject: Re: Kerby release Le 04/06/15 02:38, Zheng, Kai a écrit : > 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? Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-) > >>> 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? Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do. The way to do it is to have special Maven prodiles to build all the packages you want. > >>> 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 can create those versions in JIRA. The problem is that we already have existing version for Kerberos : https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel Which is a bit strange considering we never ever released any Kerberos code ! I think it's related to the ApacheDS releases. I will remove those versions. I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ? > 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? Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module. Wdyt ?
