Hi, Sorry for being pushy. The thing, I want to know is: What steps need to be taken to create a release which contains our ported extension activities? Should we port them to another branch? Are there features which we should help implementing (Jacob?)?
We need an "official" source + binary of the Apache Foundation of Apache ODE including support of the extension activities. It might be possible that an alpha or beta version also works fine. I think, the correlation between source + binary is also there and it has a touch of a release. So maybe a beta release of the current state is possible without much effort from your side? O:-) Cheers, Oliver 2018-02-21 13:40 GMT+01:00 Oliver Kopp <kopp....@gmail.com>: > 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/ >> > >
