ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Kopp <kopp....@gmail.com>
Subject Re: Extension activities
Date Fri, 02 Feb 2018 14:57:18 GMT
Hi,


2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik.bp@gmail.com>:

> I dont have a timeline as of yet. The trunk has lot of changes. We need to
> release the new JACOB implementation. Revisit the clustering implementation
> based on hazelcast. We need to test migrations from 1.3.x versions from
> java serialization to json based serialization. We need to document these.
> All this is sitting on the trunk.
>

Oh, wow, this sounds like much work.

Can't we rethink the release model? I am pretty impressed, what Angular is
doing. They seem to follow "Release early, release often" (
https://en.wikipedia.org/wiki/Release_early,_release_often ) very close and
they are not afraid of getting issue reports.

You are doing an amazing job at Apache ODE. It should be possible that your
work reaches the public very soon: New features and fixes should be
released soon and not be kept hidden for a long time.

I would propose the following:

1. Start using semantic versioning - https://semver.org/
2. Make sure that the each of the points you listed are marked as
openedissue
3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
with ODE 1.x (Jacob-JSON things)
4. Work on the JSON migration from java serialized jacob states to json
based
5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
1.3.x

Reasoning:

1. The 1.x line can still be maintained as rock-solid engine implementation
for business users
2. Starting from 3.x, ODE is a fast-moving project, which can include
contributions from external fast and also have the possibility to "release
early, release often"

I would also propose to have the "master" branch always release ready: All
tests are green.

WDYT?

Cheers,

Oliver
--
http://github.com/koppor/

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