brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: Apache Brooklyn 1.0 release
Date Thu, 05 Oct 2017 11:09:21 GMT
Hi all,

I approach this question as "what is essential for a 1.0 release", 
versus nice-to-have. I think pretty much every feature/change is 
nice-to-have and can be developed incrementally - if it's ready in time 
for a 1.0 then great, otherwise it will go in 1.x or 2.x.

I personally have treated each 0.x Apache Brooklyn release as being 
suitable for production use, because there have been enterprises using 
it in production! As a community, we've been behaving as though it is a 
1.x (with our deprecation policy, our attitude to backards 
compatibility, etc).

To answer the individual comments/questions.

**Basic Auth**
I agree we want it, but it's not a blocker. Enterprises have been 
getting by without it, e.g. using the ldap integration [1].

Let's move the basic-auth conversation into a separate "PROPOSAL" 
thread, and see if contributors in the community get it done in time for 
a 1.0 release.

**Feature Complete**
I believe we are "feature complete enough" for a 1.0.0.  There are no 
missing features that block our existing production users, but there are 
certainly things they'd like to see added incrementally.

We will never be "feature complete". We will always want to improve 
Brooklyn, and we should do that incrementally with subsequent 1.x releases.

**Great usability**
I'm sure usability could be improved. However, I think it's good enough 
for a 1.0, and can be improved incrementally.

**freeze our API**
Our deprecation policy and approach to backwards compatibility means we 
are already very careful in how we change our API.

The API will not be "frozen" - but it is stable.

**accept a stricter deprecation policy**
The deprecation policy was discussed in [2], but never formally 
documented on our web-site!

We have been conservative (treating it like a 1.x): we don't delete 
public api stuff without first deprecating, and we wait at least a 
couple of releases before deleting deprecated code.

What constitutes our "public api" can be a little blurred. Some 
downstream projects and power users have hooked into things that were 
not originally thought of as "public" (but not clearly marked as 
"internal" either). We have therefore been conservative about 
deprecating and deleting those as well.

**anything to deprecate before 1.0**
I think that's the same question as we ask for every release - it being 
1.0 is no different.

**removed every deprecated thing that we can**
If something was only deprecated in 0.12, I don't think we should delete 
it in 1.0. We should keep it for a minimum length of time as well so 
that upgrades are relatively pain-free for our users. Some enterprises 
are very conservative about upgrade (e.g. having an internal upgrade 
cycle, only taking new versions every 3 or 6 months).

To me, it's the same question as for every release: have we deleted old 
deprecated code.

**Do we have great documentation**
I'd reword this as "is our documentation good enough?"

We should certainly run through the tutorials, examples etc to make sure 
it's accurate - but that applies to every release.

Docs and website can and should be improved incrementally, rather than 
requiring a big bang for 1.0.

**Do we have a great website**
I'd reword that as "is our website good enough?"

**Will the blueprints in the wider community be compatible**
Yes - based on our existing approach to deprecation and backwards 
compatibility, we should not be breaking them when releasing 1.0!


[2], e-mail thread 
"Deprecation guarantees/policy?"

View raw message