ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Kopp <kopp....@gmail.com>
Subject Re: Extension activities
Date Wed, 21 Feb 2018 16:10:34 GMT
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