Oliver, Apache Ci is Jenkins, code pushes will trigger the build almost immediately and snapshots are availavle in the Apache snapshot repo.As I have already responded that we cannot market/expose snapshot artifacts to the users as per the organization policy no matter which CI tools one proposes to use.
What is your idea behind CI-Pipeline? regards, sathwik On Fri, Feb 23, 2018 at 5:02 PM, Sathwik B P <sathwik...@gmail.com> wrote: > Hi Michael, > > Just a quick jot down of tasks for JACOB. Migration is another, need to > see what is missing in JACOB. > > JACOB [Release branch (2.0a) - compatible with the ODE trunk branch] > ------------------------------------------------------------ > ------------------------------------------- > 1) Update pom > -- Upgrade Jackson to latest stable release > -- JDK 8 > 2) Lookout for patterns in source as indicated in the CVE [ > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson]. > 3) Make a new CI build for the 2.0a-JDK 8. > 4) Run the ODE trunk build to take up latest jacob snapshot. > 5) Look out for any JACOB open JIRA issues. [issues.apache.org/jira/ > browse/JACOB] > > Migrations testing from 1.3.7 > ------------------------------ > 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction > manager on TOMCAT or use the Embedded ODE Tomee distro. > 2) Deploy a prrocess and run an instance of the process. > 3) Configure the ODE trunk to the same external database. Run database > migration scripts [need to check if there is any required]. > 4) Do we need to recompile the process binary[.cbp file] to new OModel? > This is the real thing. > 5) Complete the running process instance. Runtime processing state > migration would be tested. > 6) Create a fresh process instance on the trunk and complete the running > instance. > 7) Verify all the exmaple processes in similar fashion. > > Lets see how it goes from here. > > regards, > sathwik > > On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mhahn....@gmail.com> wrote: > >> Hi Sathwik, >> >> I could commit to support you with the releasing (new JACOB >> implementation, ODE) and to help you by taking up features/issues on the >> trunk and fix/test them, e.g., implementation of migration from java >> serialized jacob states to json based jacob states as mentioned by Tammo. >> >> Would it be possible to create a consolidated roadmap/task list to >> exactly define the tasks/steps necessary for the different releases? >> So that everybody that wants to contribute is able to do so because at >> the moment it is hard to get an idea what the open points are (at least >> from my perspective). >> If I can help with that, just let me know :-) >> >> Best regards, >> Michael >> >> -----Ursprüngliche Nachricht----- >> Von: Sathwik B P [mailto:sathwik...@gmail.com] >> Gesendet: Donnerstag, 22. Februar 2018 08:07 >> An: dev@ode.apache.org >> Betreff: Re: Extension activities >> >> Oliver, >> >> What is your commitment towards continued interest in developing ODE >> further beyond the extension activities? [We are on the verge of zero >> project activity]. >> We can offer committership. >> >> Trunk is RAW code, never tested. We also probably need to see if there >> are any security concerns with respect to JSON serialization used in the >> new Serialization mechanism, I vaguely remember as there was a flag raised >> on it sometime ago on a different project. >> We can probably look for an Alpha release unless the PMC disagrees. This >> process will require quite an effort on the administrative front. >> With my limited bandwidth since I only contribute during my free time, >> it's going to be quite a task. I have the 1.3.8 release process on my plate. >> >> What do you mean by "correlation between source + binary"? >> >> regards, >> sathwik >> >> On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <kopp....@gmail.com> wrote: >> >> > 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/ >> > >> >> > > >> > > >> > >> >> >
