https://www.apache.org/dev/release-publishing.html
CD gets a little tricky given the above. Personally, I'd like to see an initial release before worrying about the CD portion (but I have a non-binding vote here) On Wed, Oct 3, 2018 at 10:21 AM, Moyer, Steven William <[email protected]> wrote: > I've read through a few of the release documents for other Apache > Directory projects and have a few questions for the team. With SCIMple > we've been gradually moving towards having a continuous delivery workflow > and, while we've still got a ways to go, I'm wondering what that would look > like within the context of the Apache Directory project. Like Mockito, > we're envisioning a future where every commit (to the develop branch) might > be released. Larger changes to the code would be developed on feature > branches until they're ready to be merged. > > > At the moment I'm a bit concerned because we've released the old PSU > SCIMple project three times since the project was moved here - simply > because we were fixing bugs that had to be addressed to be SCIM compliant > and we don't have a process in place to release Apache SCIMple yet. This > in my opinion is dangerous as we could end up with fixes that aren't > "forward-ported" to Apache SCIMple. Clearly we also don't want to call for > a vote several times a week or even several times a month. > > > Looking at the ApacheDS project, I think many of the listed steps are > taken care of by our use of the jgitflow plugin - the creation of an RC > branch, tagging and management of the POM versions all happens > automatically. Since this is a library, some of the other steps aren't > applicable at all (building an installer). In any case, I think it's worth > having a discussion about what an Apache Directory CD project would look > like. > > > As an aside, there was a previous thread that referenced changes to the > Apache release requirements. I couldn't find that document at all so if > someone would be nice enough to provide a link, I'll continue my research > there. > > > Thanks, > > > Steve >
