Hi, I think, it's a chiggen-egg problem.
Why not establish a more modern release-early-release-often cycle to show activity to the community? What is hindering a CI pipeline? This could also ease jumping in this project.I have experience with CircleCI and Travis if that helps. This could also kick-off a Google Summer-of-Code project somehow? Cheers, Oliver 2018-02-03 5:26 GMT+01:00 Sathwik B P <sathwik...@gmail.com>: > 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/ >