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/
> > >>
> > >
> > >
> >
>
>
