Inline...
Cheers,
Hadrian
On 11/18/2015 04:27 AM, Richard Downer wrote:
All,
To answer a few different points...
brooklyn or brooklyn-core: I'd definitely call it brooklyn-core, or
brooklyn-server, or something, but definitely not the bareword
"brooklyn". I'm assuming that we'll still want an all-in-one
ready-to-run binary download for developers, and that should be named
"brooklyn". IMO it would be too confusing to have "brooklyn" (which is
not immediately useful to a newbie as it lacks a UI) and
"brooklyn-full" or "brooklyn-workstation" for people who just want to
download it and run it.
Agree. I realized that brooklyn-server is also an option to
brooklyn-core, but I like core a bit more. On the distro part, there are
projects that ship multiple assemblies (distros) such as Karaf, that has
the full karaf, karaf-minimal, etc.
An option would be to have brooklyn-distro as a git repo with as many
flavors of distros as we wish. This solves the circular deps issue as well.
brooklyn-library: we've discussed in the past that we want to move
away from the all-Java blueprints as much as possible. So I'd be in
favour of this module, with the medium-long term aim to be to empty it
completely :-)
+1
Versioning: I think these all need to be versioned in unison, like
jclouds is. Having different versions will be a recipe for confusion:
"that bug is fixed in v1.2.3. You already have that? I meant v1.2.3 of
the core library, not the UI. It's stopped working? Ah, v1.2.3 of the
core needs at least version 1.3.2 of the UI."
+0.5. I agree, but I don't see it as a critical issue. The reality is
that particularly in the distributed deployments, cloud computing space
you will see many versions deployed at the same time in an environment,
especially during migrations. Brooklyn will be no exception I assume.
Also, following the semantic versioning rules, I would assume that any
v1.x.x of brooklyn should work with v1.0.0 of the api, which means that
any 1.y.y version should work (plus/minus some features) because it uses
the same api. The implication should be that there should be no changes
between v1.x.y and v1.x.0 in the api packages and any changes from 1.x.0
in the api must be backwards compatible with 1.0.0. Which is very close
to what we're doing today by using deprecation and beta annos.
Richard.
On 18 November 2015 at 09:04, Andrea Turli
<[email protected]> wrote:
Personally I would like to see the apache/incubator-brooklyn carved
up as
follows:
* apache/brooklyn
* apache/brooklyn-ui
* apache/brooklyn-library
+ 1 to
* apache/brooklyn
* apache/brooklyn-library
I'm still not entirely convinced that apache/brooklyn without the UI shows
off the entire potential of brooklyn, but no strong feelings.
Any comments?
Andrea
