10:18 a.m.
Hi Pete.
I was just doing a community release of 1.2.2.Final today and was
thinking about the CLI. Do you have any thoughts on how to
version/release the CLI whenever we do a community release?
Also, any thoughts on whether/how we should include the CLI in the
community distributions (zip files)?
-Eric
PS: @apiman-dev subscribers - feel free to offer thoughts/opinions! :)
2:42 p.m.
Hi Eric.
Thanks for looking at this. We have a few versioning options:
1. Keep versioning in sync with the main distribution
2. Keep the current versioning scheme (not milestone based, generally
bumped on major feature inclusion or sufficient number of fixes)
3. Version based on hitting milestones (containing planned features)
One of the benefits of approach 1 would be that compatibility between the
CLI and the core might be clearer to a user if the versions match. One of
its potential disadvantages would be in coupling the two, the CLI might lag
behind core if a major change happens.
As far as distribution is concerned, inclusion in the community ZIP files
seems like a sensible option. Do you have any suggestions on folder
structure? It's one (uber-) JAR and the bat/sh scripts right now.
All the best,
Pete
On Mon, 29 Feb 2016, 16:18 Eric Wittmann, <eric.wittmann(a)redhat.com> wrote:
Hi Pete.
I was just doing a community release of 1.2.2.Final today and was
thinking about the CLI. Do you have any thoughts on how to
version/release the CLI whenever we do a community release?
Also, any thoughts on whether/how we should include the CLI in the
community distributions (zip files)?
-Eric
PS: @apiman-dev subscribers - feel free to offer thoughts/opinions! :)
12:49 p.m.
For versioning of the CLI, I would probably prefer option #2 to make it
easier for users. That should probably be paramount. The consequence,
as you mention, is that the CLI needs to be kept up to date. But I
think that might actually be a benefit, not a disadvantage. :) It'll
force the issue. Any breakage between the server and the CLI in a
particular version would be considered a bug.
As for packaging with the distro - it will depend on *which* distro.
For the wildfly distro we should put the *.sh/*.bat files in $root/bin
and the JAR in $root/bin/apiman.
In Tomcat I think we should put the scripts AND the JAR in $root/bin.
The questions then is how do we get the CLI included in the distro? The
distro is currently built by maven (maven assembly). Since the CLI
isn't a maven project, I wonder what the proper way is to pull it in.
Thoughts?
-Eric
On 3/2/2016 3:42 PM, Pete Cornish wrote:
Hi Eric.
Thanks for looking at this. We have a few versioning options:
1. Keep versioning in sync with the main distribution
2. Keep the current versioning scheme (not milestone based, generally
bumped on major feature inclusion or sufficient number of fixes)
3. Version based on hitting milestones (containing planned features)
One of the benefits of approach 1 would be that compatibility between
the CLI and the core might be clearer to a user if the versions match.
One of its potential disadvantages would be in coupling the two, the CLI
might lag behind core if a major change happens.
As far as distribution is concerned, inclusion in the community ZIP
files seems like a sensible option. Do you have any suggestions on
folder structure? It's one (uber-) JAR and the bat/sh scripts right now.
All the best,
Pete
On Mon, 29 Feb 2016, 16:18 Eric Wittmann, <eric.wittmann(a)redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:
Hi Pete.
I was just doing a community release of 1.2.2.Final today and was
thinking about the CLI. Do you have any thoughts on how to
version/release the CLI whenever we do a community release?
Also, any thoughts on whether/how we should include the CLI in the
community distributions (zip files)?
-Eric
PS: @apiman-dev subscribers - feel free to offer thoughts/opinions! :)
3223
days inactive
3227
days old
2 comments
2 participants
participants (2)
-
Eric Wittmann -
Pete Cornish