ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bakker <>
Subject Re: Towards a new release and baselining support...
Date Wed, 13 Nov 2013 13:08:21 GMT
+1 for purging the old MA
+1 for semantic versioning of the release itself. This should reflect the
largest change on the bundle level, which on itself should reflect the
largest change on package level.


On Wed, Nov 13, 2013 at 1:42 PM, Marcel Offermans <> wrote:

> On 13 Nov 2013, at 13:29 , Bram de Kruijff <> wrote:
> > On Wed, Nov 13, 2013 at 10:17 AM, Marcel Offermans
> > <> wrote:
> >> As you all know, a lot of things have happened recently within the ACE
> project. We’ve rewritten the complete management agent, added quite a few
> features to the server and squashed bugs. With all of this work done I feel
> we should start working towards a new release now, but I’d like to get
> everbody’s opinion and check if there are things we forgot about that
> really need to make it into a new release.
> >
> > A big question is what we will do with the 'old' management agent. At
> > present that code is still scattered throughout several projects. So..
> > will we keep supporting it, deprecate it until the next, or purge it?
> > I think installed base is low en keeping it around surely will give a
> > lot of overhead in maintaining the codebase and moving forward on
> > interfaces. For that reason I would argue to purge it.
> I agree to purge it, as described in ACE-424 [1].
> > What will the (semantic) version of the release be? On the agent side
> > it feels like a major.. but that may depend on what we do with the old
> > one.
> First question is *do* we semantically version the release itself? I think
> we should as I see no reason to use a different versioning scheme.
> If so, I would be surprised if we don’t end up calling this 2.0.0 as I
> just broke an API in a backward incompatible way because I feel it was
> wrong (an interface extending ManagedService for no good reason).
> Greetings, Marcel
> [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message