Hi Oliver, May be, we wait to see for the kind of involvment in the DEV community which justifies the release proposal. Head back to the run up of 1.3.7 release on the ODE-1.3.x branch and look for the kind of involvement of devs and also consider the time that these developers spend on contributing to ODE and then probably revisit the release cycles.
ODE 1.4 was envisaged to be a major GA release with new features, but due to lack of involvement in the community it has not seen the light of the day. I would encourage developers to take up features/issues on the trunk and fix/test them and share information to the community, so that the PMC can make a sound judgement about releases. We would definitely like to see fresh blood coming into the community. regards, sathwik On Feb 2, 2018 20:27, "Oliver Kopp" <kopp....@gmail.com> wrote: Hi, 2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik...@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/
