directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: SCIMple release process
Date Wed, 03 Oct 2018 20:53:53 GMT

Le 03/10/2018 à 16:21, Moyer, Steven William a écrit :
> 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.

That is not going to fly, if you have many commits a day...

Keep in mind that each release must be voted by at least 3 PMC members,
with a grae period of 3 days !

Now releasing and packaging are 2 different things.

There is nothing bad in providing nightly build, but The ASF will
certainly not endorse them.

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

It's all about what we provide, as a foundation. We deliver products
that should be stable enough to be used at wide. If a project requires
numerous corrections, with many release a day/week or even month, it
starts to be problematic for our users.

In a way, Jenkins has followed the suggest path : as many release as you
have commits. It ended i a pure nightmare for users, as you never know
what is a stable enough version to use in production. It's also a
nightmare for mainiainer who almost *NEVER* know which exact version
users are havig trouble with. Trust me on that, people rarely say 'I
have an issue with ApacheDS Version X.Y.Z'. Imagine the mess if you have
2 releases a day to simply move back to one of them which is 6 months
old (ie 300 releases have flewn since the one they have trouble with...)

Nightly build, OTOH, are not a problem (we have such things for Studio).

The only big advantage I see for frequent releases (up to a release per
commit) is that you can check that the produced packages are valid and
that the packaging has not been broken by the last commit. But I'm not
buying the idea that we should have official ASF release at that frequency.

Also consider that each release must be voted and get 3 +1. We all have
day job, and if one of the required PMC member cannot check the release
(which *is* a costly process), then your release is blocked. With the
different TZ, this is even more impracticable...

Last, no least, remember that The ASF uses a mirroring system, and it
may take several hours for a release to be propagated on those remote
servers :

As you can see, depending on how the mirrors crontabs are set, packages
may not be visible to users, which would be a pain.

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

Those steps could have easily been automated. It's just that I like to
check each one of them was successful before moving to the next step.

 Since this is a library, some of the other steps aren't applicable at
all (building an installer).

Prett much like for the LDAP API, which is faster and simpler to package.

 In any case, I think it's worth having a discussion about what an
Apache Directory CD project would look like.

I would say that this thread is perfect for such a discussin. We can
fork it if we decide to diverge from the current release process (which
*is* an option, assuming it's approved by teh board).

Also note that official releases are one thing, security releases are a
very different beast. Nothing should forbid us to cut an immediate
release in such a case !

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

Me neither...
Emmanuel Lecharny

View raw message