ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sathwik B P <sathwik...@gmail.com>
Subject Re: Extension activities
Date Thu, 22 Feb 2018 07:06:53 GMT
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.dev@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.dev@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.bp@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.dev@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >>
> >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik.bp@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/
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message