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!
**media**
Yes!
[1]
https://github.com/apache/brooklyn-server/blob/master/rest/rest-resources/src/main/java/org/apache/brooklyn/rest/security/provider/LdapSecurityProvider.java
[2] http://markmail.org/message/ogdq2xyio7rjgs56, e-mail thread
"Deprecation guarantees/policy?"
