You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Duncan Godwin <dr...@apache.org> on 2017/10/03 15:33:11 UTC
Apache Brooklyn 1.0 release
Hi All,
Following the release last week of Apache Brooklyn 0.12.0 I propose that we
make the next version of Apache Brooklyn 1.0.0.
Apache Brooklyn is robust, stable, feature rich and being used in
production by multiple enterprises. Our deprecation policy means we haven't
treated it like a 0.x release in a very long time.
With 0.12.0, we did the last major thing needed before a 1.0 release: we
switched to Karaf as the primary distribution and we deprecated the
"classic mode". What does everyone think?
Many thanks
Duncan
Re: Apache Brooklyn 1.0 release
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
+1
On Tue, 3 Oct 2017 at 18:34 Aled Sage <al...@gmail.com> wrote:
> +1
>
>
> On 03/10/2017 16:33, Duncan Godwin wrote:
> > Hi All,
> >
> > Following the release last week of Apache Brooklyn 0.12.0 I propose that
> we
> > make the next version of Apache Brooklyn 1.0.0.
> >
> > Apache Brooklyn is robust, stable, feature rich and being used in
> > production by multiple enterprises. Our deprecation policy means we
> haven't
> > treated it like a 0.x release in a very long time.
> >
> > With 0.12.0, we did the last major thing needed before a 1.0 release: we
> > switched to Karaf as the primary distribution and we deprecated the
> > "classic mode". What does everyone think?
> >
> > Many thanks
> >
> > Duncan
> >
>
> --
Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Re: Apache Brooklyn 1.0 release
Posted by Aled Sage <al...@gmail.com>.
+1
On 03/10/2017 16:33, Duncan Godwin wrote:
> Hi All,
>
> Following the release last week of Apache Brooklyn 0.12.0 I propose that we
> make the next version of Apache Brooklyn 1.0.0.
>
> Apache Brooklyn is robust, stable, feature rich and being used in
> production by multiple enterprises. Our deprecation policy means we haven't
> treated it like a 0.x release in a very long time.
>
> With 0.12.0, we did the last major thing needed before a 1.0 release: we
> switched to Karaf as the primary distribution and we deprecated the
> "classic mode". What does everyone think?
>
> Many thanks
>
> Duncan
>
Re: Apache Brooklyn 1.0 release
Posted by Duncan Godwin <dg...@redwintechnologies.com>.
Hi All,
I think there is general consensus then, that our next release should be
1.0.0. I will change the versions on the project to reflect this.
I can imagine there will be specific things which people feel we could and
should do before a 1.0.0 release but this is perhaps a separate topic. I
suggest we should use the Apache Jira for this and tag Jira tickets which
should be addressed before as fixVersion 1.0.0 so they are all in one place
and marked as such [1].
Many thanks
Duncan
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20BROOKLYN%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.0.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
On 5 October 2017 at 13:55, Richard Downer <ri...@apache.org> wrote:
> Hi all,
>
> Improving our authentication is a good feature to have, but I don't think
> it's a blocker to a 1.0 release. I'd love to see this feature, but I don't
> think we need to hold back 1.0 for it (better to think such a feature
> through properly than to try and rush it into the next release.)
>
> Andrea, I've looked at readthedocs myself - I love the idea of making the
> drudgery of doc generation tooling Somebody Else's Problem, but when I last
> looked, it wasn't suited to the way our user guide was written. It would
> have needed quite a lot of manual effort to migrate from our home-grown
> tooling into the way that readthedocs wants things to be written. See my
> response[1] to Thomas' thread for a bit more.
>
> [1]
> https://lists.apache.org/thread.html/15b819cdecdcb717aa45e2efc7e4e5
> d3f1fcd491d1255a8aa72cd1c7@%3Cdev.brooklyn.apache.org%3E
>
> On 5 October 2017 at 11:22, Andrea Turli <an...@cloudsoft.io> wrote:
>
> > +1 to stronger authN
> >
> > FYI I've quickly tried readthedocs -- see
> > https://readthedocs.org/projects/brooklyn-docs/ and it is nice and free,
> > maybe we should consider it for the website. It is an hosted service well
> > integrated with github which offers full text seatrch out of the box.
> > Many others ASF projects already use them, it's maybe worth a try.
> >
> > My two cents,
> > Andrea
> >
> >
> >
> > On 5 October 2017 at 12:07, Thomas Bouron <thomas.bouron@cloudsoftcorp.
> com
> > >
> > wrote:
> >
> > > I would agree with Geoff on the auth. I think it would be nice to move
> to
> > > JWT for 1.0.
> > >
> > > I would also point out the Brooklyn website. I'm the one to blame on
> > this,
> > > I redesigned the home page but not the rest (mostly due to the
> currently
> > > complexity of it)
> > > I'll send a proposal on this today.
> > >
> > > Best.
> > >
> > > On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <
> > geoff.macartney@cloudsoft.io>
> > > wrote:
> > >
> > > > +1 with observation that there are still some things we might want to
> > do
> > > > before making that 1.0 release. (In re. Richard's comment about "Are
> we
> > > > feature complete", you may think we are not.)
> > > >
> > > > For example something I think it would be good to do before
> announcing
> > a
> > > > 1.0 is to get away from basic auth on the UI and REST API and having
> a
> > > > session token based approach, perhaps based on JWT tokens. (Don't
> like
> > > > storing the auth credentials for the CLI)
> > > >
> > > > That's one example but you may have your own suggestions - shout out!
> > > >
> > > > Geoff
> > > >
> > > >
> > > >
> > > > On Wed, 4 Oct 2017 at 16:41 Richard Downer <ri...@apache.org>
> wrote:
> > > >
> > > > > +1 with conditions :-)
> > > > >
> > > > > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that
> > we
> > > > > would get ASF PR involved to generate a bit of buzz around this,
> and
> > > > > possibly approach some of our commercial users and friends to chip
> in
> > > > with
> > > > > some PR too.
> > > > >
> > > > > But going to 1.0 (and generating some media buzz around it) brings
> > > > > responsibilities. If the media buzz brings in new users, we want to
> > > make
> > > > > sure our usability is as high as possible - this covers the app
> > itself,
> > > > as
> > > > > well as the website and the documentation.
> > > > >
> > > > > So to answer your question with some more questions...
> > > > >
> > > > > Are we feature-complete?
> > > > >
> > > > > Do we have great usability? Good user stories for all our types of
> > > users?
> > > > >
> > > > > Are we happy to freeze our API in its current state?
> > > > >
> > > > > Are we happy to accept a stricter deprecation policy going forward?
> > > > >
> > > > > Is there nothing that we want to deprecate before 1.0? (That would
> > > imply
> > > > > another 0.x release cycle)
> > > > >
> > > > > Have we removed every deprecated thing that we can? (If something
> is
> > > > > deprecated but cannot be removed, why?)
> > > > >
> > > > > Do we have great documentation?
> > > > >
> > > > > Do we have a great website?
> > > > >
> > > > > Does our documentation and examples reflect the "best" (not
> > deprecated,
> > > > > outdated or suboptimal) way of doing things?
> > > > >
> > > > > Will the blueprints in the wider community be compatible with the
> > > > proposed
> > > > > 1.0 release or do they need updating? (We will need to work with
> > those
> > > > > blueprint owners to get the blueprints updated.)
> > > > >
> > > > > Are we prepared to personally get involved in a media and
> visibility
> > > > push?
> > > > > (e.g. using our own Twitter, networks, getting more people involved
> > in
> > > > > managing the official Apache Brooklyn social media channels, etc.)
> > > > >
> > > > > Are we prepared - in the event of a successful media blitz - to
> > handle
> > > > more
> > > > > users coming to this list, IRC, Twitter etc. looking for help?
> > > > >
> > > > >
> > > > > If we can answer "yes" to all of these questions, then we are ready
> > to
> > > > > release 1.0. If any of these questions is answered "no" or "maybe"
> > then
> > > > we
> > > > > should wait, or consider making a 0.13.0 release first.
> > > > >
> > > > > Richard.
> > > > >
> > > > >
> > > > > On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org>
> > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Following the release last week of Apache Brooklyn 0.12.0 I
> propose
> > > > that
> > > > > we
> > > > > > make the next version of Apache Brooklyn 1.0.0.
> > > > > >
> > > > > > Apache Brooklyn is robust, stable, feature rich and being used in
> > > > > > production by multiple enterprises. Our deprecation policy means
> we
> > > > > haven't
> > > > > > treated it like a 0.x release in a very long time.
> > > > > >
> > > > > > With 0.12.0, we did the last major thing needed before a 1.0
> > release:
> > > > we
> > > > > > switched to Karaf as the primary distribution and we deprecated
> the
> > > > > > "classic mode". What does everyone think?
> > > > > >
> > > > > > Many thanks
> > > > > >
> > > > > > Duncan
> > > > > >
> > > > >
> > > >
> > > --
> > >
> > > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > > https://cloudsoft.io/
> > > Github: https://github.com/tbouron
> > > Twitter: https://twitter.com/eltibouron
> > >
> >
>
Re: Apache Brooklyn 1.0 release
Posted by Richard Downer <ri...@apache.org>.
Hi all,
Improving our authentication is a good feature to have, but I don't think
it's a blocker to a 1.0 release. I'd love to see this feature, but I don't
think we need to hold back 1.0 for it (better to think such a feature
through properly than to try and rush it into the next release.)
Andrea, I've looked at readthedocs myself - I love the idea of making the
drudgery of doc generation tooling Somebody Else's Problem, but when I last
looked, it wasn't suited to the way our user guide was written. It would
have needed quite a lot of manual effort to migrate from our home-grown
tooling into the way that readthedocs wants things to be written. See my
response[1] to Thomas' thread for a bit more.
[1]
https://lists.apache.org/thread.html/15b819cdecdcb717aa45e2efc7e4e5d3f1fcd491d1255a8aa72cd1c7@%3Cdev.brooklyn.apache.org%3E
On 5 October 2017 at 11:22, Andrea Turli <an...@cloudsoft.io> wrote:
> +1 to stronger authN
>
> FYI I've quickly tried readthedocs -- see
> https://readthedocs.org/projects/brooklyn-docs/ and it is nice and free,
> maybe we should consider it for the website. It is an hosted service well
> integrated with github which offers full text seatrch out of the box.
> Many others ASF projects already use them, it's maybe worth a try.
>
> My two cents,
> Andrea
>
>
>
> On 5 October 2017 at 12:07, Thomas Bouron <thomas.bouron@cloudsoftcorp.com
> >
> wrote:
>
> > I would agree with Geoff on the auth. I think it would be nice to move to
> > JWT for 1.0.
> >
> > I would also point out the Brooklyn website. I'm the one to blame on
> this,
> > I redesigned the home page but not the rest (mostly due to the currently
> > complexity of it)
> > I'll send a proposal on this today.
> >
> > Best.
> >
> > On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <
> geoff.macartney@cloudsoft.io>
> > wrote:
> >
> > > +1 with observation that there are still some things we might want to
> do
> > > before making that 1.0 release. (In re. Richard's comment about "Are we
> > > feature complete", you may think we are not.)
> > >
> > > For example something I think it would be good to do before announcing
> a
> > > 1.0 is to get away from basic auth on the UI and REST API and having a
> > > session token based approach, perhaps based on JWT tokens. (Don't like
> > > storing the auth credentials for the CLI)
> > >
> > > That's one example but you may have your own suggestions - shout out!
> > >
> > > Geoff
> > >
> > >
> > >
> > > On Wed, 4 Oct 2017 at 16:41 Richard Downer <ri...@apache.org> wrote:
> > >
> > > > +1 with conditions :-)
> > > >
> > > > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that
> we
> > > > would get ASF PR involved to generate a bit of buzz around this, and
> > > > possibly approach some of our commercial users and friends to chip in
> > > with
> > > > some PR too.
> > > >
> > > > But going to 1.0 (and generating some media buzz around it) brings
> > > > responsibilities. If the media buzz brings in new users, we want to
> > make
> > > > sure our usability is as high as possible - this covers the app
> itself,
> > > as
> > > > well as the website and the documentation.
> > > >
> > > > So to answer your question with some more questions...
> > > >
> > > > Are we feature-complete?
> > > >
> > > > Do we have great usability? Good user stories for all our types of
> > users?
> > > >
> > > > Are we happy to freeze our API in its current state?
> > > >
> > > > Are we happy to accept a stricter deprecation policy going forward?
> > > >
> > > > Is there nothing that we want to deprecate before 1.0? (That would
> > imply
> > > > another 0.x release cycle)
> > > >
> > > > Have we removed every deprecated thing that we can? (If something is
> > > > deprecated but cannot be removed, why?)
> > > >
> > > > Do we have great documentation?
> > > >
> > > > Do we have a great website?
> > > >
> > > > Does our documentation and examples reflect the "best" (not
> deprecated,
> > > > outdated or suboptimal) way of doing things?
> > > >
> > > > Will the blueprints in the wider community be compatible with the
> > > proposed
> > > > 1.0 release or do they need updating? (We will need to work with
> those
> > > > blueprint owners to get the blueprints updated.)
> > > >
> > > > Are we prepared to personally get involved in a media and visibility
> > > push?
> > > > (e.g. using our own Twitter, networks, getting more people involved
> in
> > > > managing the official Apache Brooklyn social media channels, etc.)
> > > >
> > > > Are we prepared - in the event of a successful media blitz - to
> handle
> > > more
> > > > users coming to this list, IRC, Twitter etc. looking for help?
> > > >
> > > >
> > > > If we can answer "yes" to all of these questions, then we are ready
> to
> > > > release 1.0. If any of these questions is answered "no" or "maybe"
> then
> > > we
> > > > should wait, or consider making a 0.13.0 release first.
> > > >
> > > > Richard.
> > > >
> > > >
> > > > On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org>
> > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > Following the release last week of Apache Brooklyn 0.12.0 I propose
> > > that
> > > > we
> > > > > make the next version of Apache Brooklyn 1.0.0.
> > > > >
> > > > > Apache Brooklyn is robust, stable, feature rich and being used in
> > > > > production by multiple enterprises. Our deprecation policy means we
> > > > haven't
> > > > > treated it like a 0.x release in a very long time.
> > > > >
> > > > > With 0.12.0, we did the last major thing needed before a 1.0
> release:
> > > we
> > > > > switched to Karaf as the primary distribution and we deprecated the
> > > > > "classic mode". What does everyone think?
> > > > >
> > > > > Many thanks
> > > > >
> > > > > Duncan
> > > > >
> > > >
> > >
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>
Re: Apache Brooklyn 1.0 release
Posted by Aled Sage <al...@gmail.com>.
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?"
Re: Apache Brooklyn 1.0 release
Posted by Andrea Turli <an...@cloudsoft.io>.
+1 to stronger authN
FYI I've quickly tried readthedocs -- see
https://readthedocs.org/projects/brooklyn-docs/ and it is nice and free,
maybe we should consider it for the website. It is an hosted service well
integrated with github which offers full text seatrch out of the box.
Many others ASF projects already use them, it's maybe worth a try.
My two cents,
Andrea
On 5 October 2017 at 12:07, Thomas Bouron <th...@cloudsoftcorp.com>
wrote:
> I would agree with Geoff on the auth. I think it would be nice to move to
> JWT for 1.0.
>
> I would also point out the Brooklyn website. I'm the one to blame on this,
> I redesigned the home page but not the rest (mostly due to the currently
> complexity of it)
> I'll send a proposal on this today.
>
> Best.
>
> On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <ge...@cloudsoft.io>
> wrote:
>
> > +1 with observation that there are still some things we might want to do
> > before making that 1.0 release. (In re. Richard's comment about "Are we
> > feature complete", you may think we are not.)
> >
> > For example something I think it would be good to do before announcing a
> > 1.0 is to get away from basic auth on the UI and REST API and having a
> > session token based approach, perhaps based on JWT tokens. (Don't like
> > storing the auth credentials for the CLI)
> >
> > That's one example but you may have your own suggestions - shout out!
> >
> > Geoff
> >
> >
> >
> > On Wed, 4 Oct 2017 at 16:41 Richard Downer <ri...@apache.org> wrote:
> >
> > > +1 with conditions :-)
> > >
> > > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that we
> > > would get ASF PR involved to generate a bit of buzz around this, and
> > > possibly approach some of our commercial users and friends to chip in
> > with
> > > some PR too.
> > >
> > > But going to 1.0 (and generating some media buzz around it) brings
> > > responsibilities. If the media buzz brings in new users, we want to
> make
> > > sure our usability is as high as possible - this covers the app itself,
> > as
> > > well as the website and the documentation.
> > >
> > > So to answer your question with some more questions...
> > >
> > > Are we feature-complete?
> > >
> > > Do we have great usability? Good user stories for all our types of
> users?
> > >
> > > Are we happy to freeze our API in its current state?
> > >
> > > Are we happy to accept a stricter deprecation policy going forward?
> > >
> > > Is there nothing that we want to deprecate before 1.0? (That would
> imply
> > > another 0.x release cycle)
> > >
> > > Have we removed every deprecated thing that we can? (If something is
> > > deprecated but cannot be removed, why?)
> > >
> > > Do we have great documentation?
> > >
> > > Do we have a great website?
> > >
> > > Does our documentation and examples reflect the "best" (not deprecated,
> > > outdated or suboptimal) way of doing things?
> > >
> > > Will the blueprints in the wider community be compatible with the
> > proposed
> > > 1.0 release or do they need updating? (We will need to work with those
> > > blueprint owners to get the blueprints updated.)
> > >
> > > Are we prepared to personally get involved in a media and visibility
> > push?
> > > (e.g. using our own Twitter, networks, getting more people involved in
> > > managing the official Apache Brooklyn social media channels, etc.)
> > >
> > > Are we prepared - in the event of a successful media blitz - to handle
> > more
> > > users coming to this list, IRC, Twitter etc. looking for help?
> > >
> > >
> > > If we can answer "yes" to all of these questions, then we are ready to
> > > release 1.0. If any of these questions is answered "no" or "maybe" then
> > we
> > > should wait, or consider making a 0.13.0 release first.
> > >
> > > Richard.
> > >
> > >
> > > On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org>
> wrote:
> > >
> > > > Hi All,
> > > >
> > > > Following the release last week of Apache Brooklyn 0.12.0 I propose
> > that
> > > we
> > > > make the next version of Apache Brooklyn 1.0.0.
> > > >
> > > > Apache Brooklyn is robust, stable, feature rich and being used in
> > > > production by multiple enterprises. Our deprecation policy means we
> > > haven't
> > > > treated it like a 0.x release in a very long time.
> > > >
> > > > With 0.12.0, we did the last major thing needed before a 1.0 release:
> > we
> > > > switched to Karaf as the primary distribution and we deprecated the
> > > > "classic mode". What does everyone think?
> > > >
> > > > Many thanks
> > > >
> > > > Duncan
> > > >
> > >
> >
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
Re: Apache Brooklyn 1.0 release
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
I would agree with Geoff on the auth. I think it would be nice to move to
JWT for 1.0.
I would also point out the Brooklyn website. I'm the one to blame on this,
I redesigned the home page but not the rest (mostly due to the currently
complexity of it)
I'll send a proposal on this today.
Best.
On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <ge...@cloudsoft.io>
wrote:
> +1 with observation that there are still some things we might want to do
> before making that 1.0 release. (In re. Richard's comment about "Are we
> feature complete", you may think we are not.)
>
> For example something I think it would be good to do before announcing a
> 1.0 is to get away from basic auth on the UI and REST API and having a
> session token based approach, perhaps based on JWT tokens. (Don't like
> storing the auth credentials for the CLI)
>
> That's one example but you may have your own suggestions - shout out!
>
> Geoff
>
>
>
> On Wed, 4 Oct 2017 at 16:41 Richard Downer <ri...@apache.org> wrote:
>
> > +1 with conditions :-)
> >
> > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that we
> > would get ASF PR involved to generate a bit of buzz around this, and
> > possibly approach some of our commercial users and friends to chip in
> with
> > some PR too.
> >
> > But going to 1.0 (and generating some media buzz around it) brings
> > responsibilities. If the media buzz brings in new users, we want to make
> > sure our usability is as high as possible - this covers the app itself,
> as
> > well as the website and the documentation.
> >
> > So to answer your question with some more questions...
> >
> > Are we feature-complete?
> >
> > Do we have great usability? Good user stories for all our types of users?
> >
> > Are we happy to freeze our API in its current state?
> >
> > Are we happy to accept a stricter deprecation policy going forward?
> >
> > Is there nothing that we want to deprecate before 1.0? (That would imply
> > another 0.x release cycle)
> >
> > Have we removed every deprecated thing that we can? (If something is
> > deprecated but cannot be removed, why?)
> >
> > Do we have great documentation?
> >
> > Do we have a great website?
> >
> > Does our documentation and examples reflect the "best" (not deprecated,
> > outdated or suboptimal) way of doing things?
> >
> > Will the blueprints in the wider community be compatible with the
> proposed
> > 1.0 release or do they need updating? (We will need to work with those
> > blueprint owners to get the blueprints updated.)
> >
> > Are we prepared to personally get involved in a media and visibility
> push?
> > (e.g. using our own Twitter, networks, getting more people involved in
> > managing the official Apache Brooklyn social media channels, etc.)
> >
> > Are we prepared - in the event of a successful media blitz - to handle
> more
> > users coming to this list, IRC, Twitter etc. looking for help?
> >
> >
> > If we can answer "yes" to all of these questions, then we are ready to
> > release 1.0. If any of these questions is answered "no" or "maybe" then
> we
> > should wait, or consider making a 0.13.0 release first.
> >
> > Richard.
> >
> >
> > On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org> wrote:
> >
> > > Hi All,
> > >
> > > Following the release last week of Apache Brooklyn 0.12.0 I propose
> that
> > we
> > > make the next version of Apache Brooklyn 1.0.0.
> > >
> > > Apache Brooklyn is robust, stable, feature rich and being used in
> > > production by multiple enterprises. Our deprecation policy means we
> > haven't
> > > treated it like a 0.x release in a very long time.
> > >
> > > With 0.12.0, we did the last major thing needed before a 1.0 release:
> we
> > > switched to Karaf as the primary distribution and we deprecated the
> > > "classic mode". What does everyone think?
> > >
> > > Many thanks
> > >
> > > Duncan
> > >
> >
>
--
Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron
Re: Apache Brooklyn 1.0 release
Posted by Geoff Macartney <ge...@cloudsoft.io>.
+1 with observation that there are still some things we might want to do
before making that 1.0 release. (In re. Richard's comment about "Are we
feature complete", you may think we are not.)
For example something I think it would be good to do before announcing a
1.0 is to get away from basic auth on the UI and REST API and having a
session token based approach, perhaps based on JWT tokens. (Don't like
storing the auth credentials for the CLI)
That's one example but you may have your own suggestions - shout out!
Geoff
On Wed, 4 Oct 2017 at 16:41 Richard Downer <ri...@apache.org> wrote:
> +1 with conditions :-)
>
> Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that we
> would get ASF PR involved to generate a bit of buzz around this, and
> possibly approach some of our commercial users and friends to chip in with
> some PR too.
>
> But going to 1.0 (and generating some media buzz around it) brings
> responsibilities. If the media buzz brings in new users, we want to make
> sure our usability is as high as possible - this covers the app itself, as
> well as the website and the documentation.
>
> So to answer your question with some more questions...
>
> Are we feature-complete?
>
> Do we have great usability? Good user stories for all our types of users?
>
> Are we happy to freeze our API in its current state?
>
> Are we happy to accept a stricter deprecation policy going forward?
>
> Is there nothing that we want to deprecate before 1.0? (That would imply
> another 0.x release cycle)
>
> Have we removed every deprecated thing that we can? (If something is
> deprecated but cannot be removed, why?)
>
> Do we have great documentation?
>
> Do we have a great website?
>
> Does our documentation and examples reflect the "best" (not deprecated,
> outdated or suboptimal) way of doing things?
>
> Will the blueprints in the wider community be compatible with the proposed
> 1.0 release or do they need updating? (We will need to work with those
> blueprint owners to get the blueprints updated.)
>
> Are we prepared to personally get involved in a media and visibility push?
> (e.g. using our own Twitter, networks, getting more people involved in
> managing the official Apache Brooklyn social media channels, etc.)
>
> Are we prepared - in the event of a successful media blitz - to handle more
> users coming to this list, IRC, Twitter etc. looking for help?
>
>
> If we can answer "yes" to all of these questions, then we are ready to
> release 1.0. If any of these questions is answered "no" or "maybe" then we
> should wait, or consider making a 0.13.0 release first.
>
> Richard.
>
>
> On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org> wrote:
>
> > Hi All,
> >
> > Following the release last week of Apache Brooklyn 0.12.0 I propose that
> we
> > make the next version of Apache Brooklyn 1.0.0.
> >
> > Apache Brooklyn is robust, stable, feature rich and being used in
> > production by multiple enterprises. Our deprecation policy means we
> haven't
> > treated it like a 0.x release in a very long time.
> >
> > With 0.12.0, we did the last major thing needed before a 1.0 release: we
> > switched to Karaf as the primary distribution and we deprecated the
> > "classic mode". What does everyone think?
> >
> > Many thanks
> >
> > Duncan
> >
>
Re: Apache Brooklyn 1.0 release
Posted by Richard Downer <ri...@apache.org>.
+1 with conditions :-)
Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that we
would get ASF PR involved to generate a bit of buzz around this, and
possibly approach some of our commercial users and friends to chip in with
some PR too.
But going to 1.0 (and generating some media buzz around it) brings
responsibilities. If the media buzz brings in new users, we want to make
sure our usability is as high as possible - this covers the app itself, as
well as the website and the documentation.
So to answer your question with some more questions...
Are we feature-complete?
Do we have great usability? Good user stories for all our types of users?
Are we happy to freeze our API in its current state?
Are we happy to accept a stricter deprecation policy going forward?
Is there nothing that we want to deprecate before 1.0? (That would imply
another 0.x release cycle)
Have we removed every deprecated thing that we can? (If something is
deprecated but cannot be removed, why?)
Do we have great documentation?
Do we have a great website?
Does our documentation and examples reflect the "best" (not deprecated,
outdated or suboptimal) way of doing things?
Will the blueprints in the wider community be compatible with the proposed
1.0 release or do they need updating? (We will need to work with those
blueprint owners to get the blueprints updated.)
Are we prepared to personally get involved in a media and visibility push?
(e.g. using our own Twitter, networks, getting more people involved in
managing the official Apache Brooklyn social media channels, etc.)
Are we prepared - in the event of a successful media blitz - to handle more
users coming to this list, IRC, Twitter etc. looking for help?
If we can answer "yes" to all of these questions, then we are ready to
release 1.0. If any of these questions is answered "no" or "maybe" then we
should wait, or consider making a 0.13.0 release first.
Richard.
On 3 October 2017 at 16:33, Duncan Godwin <dr...@apache.org> wrote:
> Hi All,
>
> Following the release last week of Apache Brooklyn 0.12.0 I propose that we
> make the next version of Apache Brooklyn 1.0.0.
>
> Apache Brooklyn is robust, stable, feature rich and being used in
> production by multiple enterprises. Our deprecation policy means we haven't
> treated it like a 0.x release in a very long time.
>
> With 0.12.0, we did the last major thing needed before a 1.0 release: we
> switched to Karaf as the primary distribution and we deprecated the
> "classic mode". What does everyone think?
>
> Many thanks
>
> Duncan
>