You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by Christian Amend <ch...@apache.org> on 2015/10/09 15:11:31 UTC
[DISCUSS] Future Release cycle of the Olingo V4 library
Hi all,
Since we now have the first stable release with our 4.0.0 version I
would like to start a discussion about the future release cycle of the
V4 library. With the V2 library there have not been many people from
the open source world involved so the Olingo members have been
releasing if they thought it was a good idea. Communication about this
was mostly done privately until the vote mail was send to the dev
list. Even with the V4 beta releases there has not been a really clear
path of what we hoped to get into the releases and when to release
them.
Since there are now more contributors I would like the Olingo
community to get to a consensus about how we as an Apache project want
to handle this in the future.
1. Should we define a feature set and log it inside JIRA. Then once
this set is implemented a release is done.
2. Should we define a time cycle e.g. 1-3 months and provide releases
even if some features are not ready.
3. A combination I could not yet think of
WDYT?
Best Regards,
Christian
Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi all,
IMHO a combination of definition of a (coarse) roadmap and feature which should be included in the next version
and a relatively fixed release cycle (around 3 months) works best.
Part of the roadmap should also to fix all known bugs.
Voting of priority of features (and hence definition which are included in next release) could be done via “dev” mailing list.
> 1. Should we define a feature set and log it inside JIRA. Then once
> this set is implemented a release is done.
> 2. Should we define a time cycle e.g. 1-3 months and provide releases
> even if some features are not ready.
> 3. A combination I could not yet think of
> On 09 Oct 2015, at 23:04, Ramesh Reddy <ra...@redhat.com> wrote:
>
> development = 0 - 1 1/2 months
> beta = 1 1/2 - 2 1/2 months
> CR/Release = 2 1/2 - 3 months
Furthermore the suggestion of Ramesh with different development phases sound good for me.
So we can first focus on implementing the feature (dev),
test intensively and polish the feature up (beta),
and then do the release (CR).
Best Regards,
Michael
Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by mibo <mi...@apache.org>.
Hi all,
to put my „two cents“ in.
I totally agree that a release must not contain critical bugs in the core parts of the library.
Accordingly we should clearly separate between the „extension“ parts and the „core“ parts.
Furthermore the suggestion of Ramesh with different development phases sound good for me.
So we can first focus on implementing the feature (alpha/dev-phase),
test intensively and polish the feature up (beta-phase with feature-freeze),
and then do the release (RC with vote).
Those „phases“ then reflected as described by Ramesh:
> In Teiid, yes we provide jars/kits available through maven repo for alpha/beta with alpha/beta tags. The master branch is always working on next SNAPSHOT.
A definition of a (coarse) roadmap with features which should be included in the next version
in combination with a (relatively) fixed release cycle (around 3 months) should fit very good for us (Olingo).
Additionally I think it would also very good if we document this as an (informal?) guideline on the homepage.
This could/should be done together with some (new/updated) guidelines for contributors/committers.
Best Regards,
Michael
> Am 21.10.2015 um 16:53 schrieb Ramesh Reddy <ra...@redhat.com>:
>
> Yes, we would to reclassify (as for user entering the JIRA it is always a blocker ;)) . Yes, JPA I am talking about V4, not V2.
>
> In Teiid, yes we provide jars/kits available through maven repo for alpha/beta with alpha/beta tags. The master branch is always working on next SNAPSHOT.
>
> Ramesh..
>
> ----- Original Message -----
>> Hi Ramesh,
>>
>> Sorry I did not see the critical part. In this case I completely agree.
>> Fixing critical issues for the core library should be part of our
>> guidelines. For "major" issues I am not entirely sure since this is the
>> default tag for new created issues and few change this. So there either
>> needs to be a reclassification by us or a discussion once we approach the
>> release which of these issues we can push to a later release IHMO.
>> Making JPA a separate project is my hope for the V4 part of Olingo. I think
>> changing the V2 part would be too much effort at this point in time :)
>> Also I completely agree with the informal releases for feedback. How does the
>> Teiid community handle this? By providing a maven build artifact with a
>> "beta" in its name or by just pointing users to the current SNAPSHOT after a
>> certain amount of time?
>>
>> Best Regards,
>> Christian
>>
>> -----Original Message-----
>> From: Ramesh Reddy [mailto:rareddy@redhat.com]
>> Sent: Mittwoch, 21. Oktober 2015 16:00
>> To: dev@olingo.apache.org
>> Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
>>
>> On Point 2, I said "crtical/Major" tag line, I am saying if something is
>> deemed as critical and major then we should make an effort to fix those. May
>> be we should limit this restriction to "core" framework, not JPA or other
>> extensions. IMO, JPA needs to be its own sub-project based on some stable
>> version Olingo, not core part of Olingo. But that not how it is set up right
>> now, and completely separate topic ;)
>>
>> Down porting is time consuming, until we get to very stable state, yes I
>> agree it is better to recommend to upgrade to newer versions, that will save
>> time.
>>
>> Yes, ALPHA, BETA should informal releases (no voting) that are there to get
>> feed back on features before final release, where as final does require
>> voting.
>>
>> Ramesh..
>>
>> ----- Original Message -----
>>> Hi Ramesh,
>>>
>>> I really like having a clear timeline. Around 3 months sounds reasonable to
>>> me as well.
>>>
>>> Point 1 sounds good and should ensure that the community is on a clear
>>> basis
>>> what to develop. I like this a lot.
>>>
>>> Point 2 worries me though. I completely agree with never downporting fixes
>>> if
>>> there is a clear workaround. I would even go as far as recommending users
>>> to
>>> upgrade to a newer version to receive a Bugfix if possible. This ensures
>>> development speed from our side.
>>> Yet personally I think that fixing all bugs is not feasible with the time I
>>> have to contribute to the project. For example the V4 client code and the
>>> V2
>>> JPA processor have been contributed to Olingo and I am not as knowledgeable
>>> in these domains as I am with the server part. So I would not want to delay
>>> a release simply because there are open client bugs that I can`t fix either
>>> because of time constraints or knowledge issues. So I would not make open
>>> bugs a blocker for a release. I completely agree with fixing as many bugs
>>> as
>>> possible before a release though.
>>> Also I hope that bugs that are a "pain" for the community will result in
>>> more
>>> contributions for fixes. This is something we are lacking right now IMHO.
>>>
>>> Another point I am not sure about is the beta release. In my opinion this
>>> is
>>> the current SNAPSHOT version. I would not perform a real beta release and
>>> publish it through all channels because I think this is a process overhead
>>> with how the release process currently goes. This includes votings on the
>>> mailing list and the verification of all release artifacts. I could think
>>> of
>>> an informal beta release where we simply change the mvn version number for
>>> a
>>> single deploy to give users a stable version to use. Or after 1,5 months we
>>> simply drop a mail to the user list to encourage users to try the current
>>> snapshot version.
>>>
>>> WDYT?
>>>
>>> Best Regards,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: Ramesh Reddy [mailto:rareddy@redhat.com]
>>> Sent: Freitag, 9. Oktober 2015 23:05
>>> To: dev@olingo.apache.org
>>> Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
>>>
>>> Christian,
>>>
>>> Thank you for reaching out to the broader community, I really appreciate
>>> it.
>>> In my experience #3 works as good policy for us in Teiid community. We
>>> release about every ~3 months (+/-2Wks). However, there are two rules we
>>> follow
>>>
>>> 1) At the beginning of the cycle, (or more towards the end of last cycle)
>>> we
>>> reach out to the community and look at current JIRAs and figure out what
>>> are
>>> the couple major features/enhancements we want to get done. These we label
>>> as "driving" factors for the release. These are must have features. Note
>>> that these could be computed from # votes received from community etc.
>>>
>>> 2) Fix ANY and ALL the bugs found in previous and current releases. Never
>>> "push" a "critical/major" bugs into another release unless there is clear
>>> workaround or alternative. Community really appreciates timely fixes of
>>> known bugs.
>>>
>>> Then there may be internal requests team need to honor <wink>, and what
>>> contributors like me would want to contribute for supporting our community
>>> <wink>. And then there are best effort enhancements, that we could push to
>>> next/future releases if they did not get done in time.
>>>
>>> At the beginning, we can set the target date for the release, and do a
>>> "beta"
>>> releases, after first month/month and half, depending upon the feature
>>> completions.
>>>
>>> development = 0 - 1 1/2 months
>>> beta = 1 1/2 - 2 1/2 months
>>> CR/Release = 2 1/2 - 3 months
>>>
>>> During this time, if you have the cadence, you can also do bug fix releases
>>> on the previous releases, depending upon the need.
>>>
>>> WDYT?
>>>
>>> Ramesh..
>>>
>>>
>>> ----- Original Message -----
>>>> Hi all,
>>>>
>>>> Since we now have the first stable release with our 4.0.0 version I
>>>> would like to start a discussion about the future release cycle of the
>>>> V4 library. With the V2 library there have not been many people from
>>>> the open source world involved so the Olingo members have been
>>>> releasing if they thought it was a good idea. Communication about this
>>>> was mostly done privately until the vote mail was send to the dev
>>>> list. Even with the V4 beta releases there has not been a really clear
>>>> path of what we hoped to get into the releases and when to release
>>>> them.
>>>>
>>>> Since there are now more contributors I would like the Olingo
>>>> community to get to a consensus about how we as an Apache project want
>>>> to handle this in the future.
>>>>
>>>> 1. Should we define a feature set and log it inside JIRA. Then once
>>>> this set is implemented a release is done.
>>>> 2. Should we define a time cycle e.g. 1-3 months and provide releases
>>>> even if some features are not ready.
>>>> 3. A combination I could not yet think of
>>>>
>>>> WDYT?
>>>>
>>>> Best Regards,
>>>> Christian
>>>>
>>>
>>
Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by Ramesh Reddy <ra...@redhat.com>.
Yes, we would to reclassify (as for user entering the JIRA it is always a blocker ;)) . Yes, JPA I am talking about V4, not V2.
In Teiid, yes we provide jars/kits available through maven repo for alpha/beta with alpha/beta tags. The master branch is always working on next SNAPSHOT.
Ramesh..
----- Original Message -----
> Hi Ramesh,
>
> Sorry I did not see the critical part. In this case I completely agree.
> Fixing critical issues for the core library should be part of our
> guidelines. For "major" issues I am not entirely sure since this is the
> default tag for new created issues and few change this. So there either
> needs to be a reclassification by us or a discussion once we approach the
> release which of these issues we can push to a later release IHMO.
> Making JPA a separate project is my hope for the V4 part of Olingo. I think
> changing the V2 part would be too much effort at this point in time :)
> Also I completely agree with the informal releases for feedback. How does the
> Teiid community handle this? By providing a maven build artifact with a
> "beta" in its name or by just pointing users to the current SNAPSHOT after a
> certain amount of time?
>
> Best Regards,
> Christian
>
> -----Original Message-----
> From: Ramesh Reddy [mailto:rareddy@redhat.com]
> Sent: Mittwoch, 21. Oktober 2015 16:00
> To: dev@olingo.apache.org
> Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
>
> On Point 2, I said "crtical/Major" tag line, I am saying if something is
> deemed as critical and major then we should make an effort to fix those. May
> be we should limit this restriction to "core" framework, not JPA or other
> extensions. IMO, JPA needs to be its own sub-project based on some stable
> version Olingo, not core part of Olingo. But that not how it is set up right
> now, and completely separate topic ;)
>
> Down porting is time consuming, until we get to very stable state, yes I
> agree it is better to recommend to upgrade to newer versions, that will save
> time.
>
> Yes, ALPHA, BETA should informal releases (no voting) that are there to get
> feed back on features before final release, where as final does require
> voting.
>
> Ramesh..
>
> ----- Original Message -----
> > Hi Ramesh,
> >
> > I really like having a clear timeline. Around 3 months sounds reasonable to
> > me as well.
> >
> > Point 1 sounds good and should ensure that the community is on a clear
> > basis
> > what to develop. I like this a lot.
> >
> > Point 2 worries me though. I completely agree with never downporting fixes
> > if
> > there is a clear workaround. I would even go as far as recommending users
> > to
> > upgrade to a newer version to receive a Bugfix if possible. This ensures
> > development speed from our side.
> > Yet personally I think that fixing all bugs is not feasible with the time I
> > have to contribute to the project. For example the V4 client code and the
> > V2
> > JPA processor have been contributed to Olingo and I am not as knowledgeable
> > in these domains as I am with the server part. So I would not want to delay
> > a release simply because there are open client bugs that I can`t fix either
> > because of time constraints or knowledge issues. So I would not make open
> > bugs a blocker for a release. I completely agree with fixing as many bugs
> > as
> > possible before a release though.
> > Also I hope that bugs that are a "pain" for the community will result in
> > more
> > contributions for fixes. This is something we are lacking right now IMHO.
> >
> > Another point I am not sure about is the beta release. In my opinion this
> > is
> > the current SNAPSHOT version. I would not perform a real beta release and
> > publish it through all channels because I think this is a process overhead
> > with how the release process currently goes. This includes votings on the
> > mailing list and the verification of all release artifacts. I could think
> > of
> > an informal beta release where we simply change the mvn version number for
> > a
> > single deploy to give users a stable version to use. Or after 1,5 months we
> > simply drop a mail to the user list to encourage users to try the current
> > snapshot version.
> >
> > WDYT?
> >
> > Best Regards,
> > Christian
> >
> > -----Original Message-----
> > From: Ramesh Reddy [mailto:rareddy@redhat.com]
> > Sent: Freitag, 9. Oktober 2015 23:05
> > To: dev@olingo.apache.org
> > Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
> >
> > Christian,
> >
> > Thank you for reaching out to the broader community, I really appreciate
> > it.
> > In my experience #3 works as good policy for us in Teiid community. We
> > release about every ~3 months (+/-2Wks). However, there are two rules we
> > follow
> >
> > 1) At the beginning of the cycle, (or more towards the end of last cycle)
> > we
> > reach out to the community and look at current JIRAs and figure out what
> > are
> > the couple major features/enhancements we want to get done. These we label
> > as "driving" factors for the release. These are must have features. Note
> > that these could be computed from # votes received from community etc.
> >
> > 2) Fix ANY and ALL the bugs found in previous and current releases. Never
> > "push" a "critical/major" bugs into another release unless there is clear
> > workaround or alternative. Community really appreciates timely fixes of
> > known bugs.
> >
> > Then there may be internal requests team need to honor <wink>, and what
> > contributors like me would want to contribute for supporting our community
> > <wink>. And then there are best effort enhancements, that we could push to
> > next/future releases if they did not get done in time.
> >
> > At the beginning, we can set the target date for the release, and do a
> > "beta"
> > releases, after first month/month and half, depending upon the feature
> > completions.
> >
> > development = 0 - 1 1/2 months
> > beta = 1 1/2 - 2 1/2 months
> > CR/Release = 2 1/2 - 3 months
> >
> > During this time, if you have the cadence, you can also do bug fix releases
> > on the previous releases, depending upon the need.
> >
> > WDYT?
> >
> > Ramesh..
> >
> >
> > ----- Original Message -----
> > > Hi all,
> > >
> > > Since we now have the first stable release with our 4.0.0 version I
> > > would like to start a discussion about the future release cycle of the
> > > V4 library. With the V2 library there have not been many people from
> > > the open source world involved so the Olingo members have been
> > > releasing if they thought it was a good idea. Communication about this
> > > was mostly done privately until the vote mail was send to the dev
> > > list. Even with the V4 beta releases there has not been a really clear
> > > path of what we hoped to get into the releases and when to release
> > > them.
> > >
> > > Since there are now more contributors I would like the Olingo
> > > community to get to a consensus about how we as an Apache project want
> > > to handle this in the future.
> > >
> > > 1. Should we define a feature set and log it inside JIRA. Then once
> > > this set is implemented a release is done.
> > > 2. Should we define a time cycle e.g. 1-3 months and provide releases
> > > even if some features are not ready.
> > > 3. A combination I could not yet think of
> > >
> > > WDYT?
> > >
> > > Best Regards,
> > > Christian
> > >
> >
>
RE: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by "Amend, Christian" <ch...@sap.com>.
Hi Ramesh,
Sorry I did not see the critical part. In this case I completely agree. Fixing critical issues for the core library should be part of our guidelines. For "major" issues I am not entirely sure since this is the default tag for new created issues and few change this. So there either needs to be a reclassification by us or a discussion once we approach the release which of these issues we can push to a later release IHMO.
Making JPA a separate project is my hope for the V4 part of Olingo. I think changing the V2 part would be too much effort at this point in time :)
Also I completely agree with the informal releases for feedback. How does the Teiid community handle this? By providing a maven build artifact with a "beta" in its name or by just pointing users to the current SNAPSHOT after a certain amount of time?
Best Regards,
Christian
-----Original Message-----
From: Ramesh Reddy [mailto:rareddy@redhat.com]
Sent: Mittwoch, 21. Oktober 2015 16:00
To: dev@olingo.apache.org
Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
On Point 2, I said "crtical/Major" tag line, I am saying if something is deemed as critical and major then we should make an effort to fix those. May be we should limit this restriction to "core" framework, not JPA or other extensions. IMO, JPA needs to be its own sub-project based on some stable version Olingo, not core part of Olingo. But that not how it is set up right now, and completely separate topic ;)
Down porting is time consuming, until we get to very stable state, yes I agree it is better to recommend to upgrade to newer versions, that will save time.
Yes, ALPHA, BETA should informal releases (no voting) that are there to get feed back on features before final release, where as final does require voting.
Ramesh..
----- Original Message -----
> Hi Ramesh,
>
> I really like having a clear timeline. Around 3 months sounds reasonable to
> me as well.
>
> Point 1 sounds good and should ensure that the community is on a clear basis
> what to develop. I like this a lot.
>
> Point 2 worries me though. I completely agree with never downporting fixes if
> there is a clear workaround. I would even go as far as recommending users to
> upgrade to a newer version to receive a Bugfix if possible. This ensures
> development speed from our side.
> Yet personally I think that fixing all bugs is not feasible with the time I
> have to contribute to the project. For example the V4 client code and the V2
> JPA processor have been contributed to Olingo and I am not as knowledgeable
> in these domains as I am with the server part. So I would not want to delay
> a release simply because there are open client bugs that I can`t fix either
> because of time constraints or knowledge issues. So I would not make open
> bugs a blocker for a release. I completely agree with fixing as many bugs as
> possible before a release though.
> Also I hope that bugs that are a "pain" for the community will result in more
> contributions for fixes. This is something we are lacking right now IMHO.
>
> Another point I am not sure about is the beta release. In my opinion this is
> the current SNAPSHOT version. I would not perform a real beta release and
> publish it through all channels because I think this is a process overhead
> with how the release process currently goes. This includes votings on the
> mailing list and the verification of all release artifacts. I could think of
> an informal beta release where we simply change the mvn version number for a
> single deploy to give users a stable version to use. Or after 1,5 months we
> simply drop a mail to the user list to encourage users to try the current
> snapshot version.
>
> WDYT?
>
> Best Regards,
> Christian
>
> -----Original Message-----
> From: Ramesh Reddy [mailto:rareddy@redhat.com]
> Sent: Freitag, 9. Oktober 2015 23:05
> To: dev@olingo.apache.org
> Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
>
> Christian,
>
> Thank you for reaching out to the broader community, I really appreciate it.
> In my experience #3 works as good policy for us in Teiid community. We
> release about every ~3 months (+/-2Wks). However, there are two rules we
> follow
>
> 1) At the beginning of the cycle, (or more towards the end of last cycle) we
> reach out to the community and look at current JIRAs and figure out what are
> the couple major features/enhancements we want to get done. These we label
> as "driving" factors for the release. These are must have features. Note
> that these could be computed from # votes received from community etc.
>
> 2) Fix ANY and ALL the bugs found in previous and current releases. Never
> "push" a "critical/major" bugs into another release unless there is clear
> workaround or alternative. Community really appreciates timely fixes of
> known bugs.
>
> Then there may be internal requests team need to honor <wink>, and what
> contributors like me would want to contribute for supporting our community
> <wink>. And then there are best effort enhancements, that we could push to
> next/future releases if they did not get done in time.
>
> At the beginning, we can set the target date for the release, and do a "beta"
> releases, after first month/month and half, depending upon the feature
> completions.
>
> development = 0 - 1 1/2 months
> beta = 1 1/2 - 2 1/2 months
> CR/Release = 2 1/2 - 3 months
>
> During this time, if you have the cadence, you can also do bug fix releases
> on the previous releases, depending upon the need.
>
> WDYT?
>
> Ramesh..
>
>
> ----- Original Message -----
> > Hi all,
> >
> > Since we now have the first stable release with our 4.0.0 version I
> > would like to start a discussion about the future release cycle of the
> > V4 library. With the V2 library there have not been many people from
> > the open source world involved so the Olingo members have been
> > releasing if they thought it was a good idea. Communication about this
> > was mostly done privately until the vote mail was send to the dev
> > list. Even with the V4 beta releases there has not been a really clear
> > path of what we hoped to get into the releases and when to release
> > them.
> >
> > Since there are now more contributors I would like the Olingo
> > community to get to a consensus about how we as an Apache project want
> > to handle this in the future.
> >
> > 1. Should we define a feature set and log it inside JIRA. Then once
> > this set is implemented a release is done.
> > 2. Should we define a time cycle e.g. 1-3 months and provide releases
> > even if some features are not ready.
> > 3. A combination I could not yet think of
> >
> > WDYT?
> >
> > Best Regards,
> > Christian
> >
>
Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by Ramesh Reddy <ra...@redhat.com>.
On Point 2, I said "crtical/Major" tag line, I am saying if something is deemed as critical and major then we should make an effort to fix those. May be we should limit this restriction to "core" framework, not JPA or other extensions. IMO, JPA needs to be its own sub-project based on some stable version Olingo, not core part of Olingo. But that not how it is set up right now, and completely separate topic ;)
Down porting is time consuming, until we get to very stable state, yes I agree it is better to recommend to upgrade to newer versions, that will save time.
Yes, ALPHA, BETA should informal releases (no voting) that are there to get feed back on features before final release, where as final does require voting.
Ramesh..
----- Original Message -----
> Hi Ramesh,
>
> I really like having a clear timeline. Around 3 months sounds reasonable to
> me as well.
>
> Point 1 sounds good and should ensure that the community is on a clear basis
> what to develop. I like this a lot.
>
> Point 2 worries me though. I completely agree with never downporting fixes if
> there is a clear workaround. I would even go as far as recommending users to
> upgrade to a newer version to receive a Bugfix if possible. This ensures
> development speed from our side.
> Yet personally I think that fixing all bugs is not feasible with the time I
> have to contribute to the project. For example the V4 client code and the V2
> JPA processor have been contributed to Olingo and I am not as knowledgeable
> in these domains as I am with the server part. So I would not want to delay
> a release simply because there are open client bugs that I can`t fix either
> because of time constraints or knowledge issues. So I would not make open
> bugs a blocker for a release. I completely agree with fixing as many bugs as
> possible before a release though.
> Also I hope that bugs that are a "pain" for the community will result in more
> contributions for fixes. This is something we are lacking right now IMHO.
>
> Another point I am not sure about is the beta release. In my opinion this is
> the current SNAPSHOT version. I would not perform a real beta release and
> publish it through all channels because I think this is a process overhead
> with how the release process currently goes. This includes votings on the
> mailing list and the verification of all release artifacts. I could think of
> an informal beta release where we simply change the mvn version number for a
> single deploy to give users a stable version to use. Or after 1,5 months we
> simply drop a mail to the user list to encourage users to try the current
> snapshot version.
>
> WDYT?
>
> Best Regards,
> Christian
>
> -----Original Message-----
> From: Ramesh Reddy [mailto:rareddy@redhat.com]
> Sent: Freitag, 9. Oktober 2015 23:05
> To: dev@olingo.apache.org
> Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
>
> Christian,
>
> Thank you for reaching out to the broader community, I really appreciate it.
> In my experience #3 works as good policy for us in Teiid community. We
> release about every ~3 months (+/-2Wks). However, there are two rules we
> follow
>
> 1) At the beginning of the cycle, (or more towards the end of last cycle) we
> reach out to the community and look at current JIRAs and figure out what are
> the couple major features/enhancements we want to get done. These we label
> as "driving" factors for the release. These are must have features. Note
> that these could be computed from # votes received from community etc.
>
> 2) Fix ANY and ALL the bugs found in previous and current releases. Never
> "push" a "critical/major" bugs into another release unless there is clear
> workaround or alternative. Community really appreciates timely fixes of
> known bugs.
>
> Then there may be internal requests team need to honor <wink>, and what
> contributors like me would want to contribute for supporting our community
> <wink>. And then there are best effort enhancements, that we could push to
> next/future releases if they did not get done in time.
>
> At the beginning, we can set the target date for the release, and do a "beta"
> releases, after first month/month and half, depending upon the feature
> completions.
>
> development = 0 - 1 1/2 months
> beta = 1 1/2 - 2 1/2 months
> CR/Release = 2 1/2 - 3 months
>
> During this time, if you have the cadence, you can also do bug fix releases
> on the previous releases, depending upon the need.
>
> WDYT?
>
> Ramesh..
>
>
> ----- Original Message -----
> > Hi all,
> >
> > Since we now have the first stable release with our 4.0.0 version I
> > would like to start a discussion about the future release cycle of the
> > V4 library. With the V2 library there have not been many people from
> > the open source world involved so the Olingo members have been
> > releasing if they thought it was a good idea. Communication about this
> > was mostly done privately until the vote mail was send to the dev
> > list. Even with the V4 beta releases there has not been a really clear
> > path of what we hoped to get into the releases and when to release
> > them.
> >
> > Since there are now more contributors I would like the Olingo
> > community to get to a consensus about how we as an Apache project want
> > to handle this in the future.
> >
> > 1. Should we define a feature set and log it inside JIRA. Then once
> > this set is implemented a release is done.
> > 2. Should we define a time cycle e.g. 1-3 months and provide releases
> > even if some features are not ready.
> > 3. A combination I could not yet think of
> >
> > WDYT?
> >
> > Best Regards,
> > Christian
> >
>
RE: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by "Amend, Christian" <ch...@sap.com>.
Hi Ramesh,
I really like having a clear timeline. Around 3 months sounds reasonable to me as well.
Point 1 sounds good and should ensure that the community is on a clear basis what to develop. I like this a lot.
Point 2 worries me though. I completely agree with never downporting fixes if there is a clear workaround. I would even go as far as recommending users to upgrade to a newer version to receive a Bugfix if possible. This ensures development speed from our side.
Yet personally I think that fixing all bugs is not feasible with the time I have to contribute to the project. For example the V4 client code and the V2 JPA processor have been contributed to Olingo and I am not as knowledgeable in these domains as I am with the server part. So I would not want to delay a release simply because there are open client bugs that I can`t fix either because of time constraints or knowledge issues. So I would not make open bugs a blocker for a release. I completely agree with fixing as many bugs as possible before a release though.
Also I hope that bugs that are a "pain" for the community will result in more contributions for fixes. This is something we are lacking right now IMHO.
Another point I am not sure about is the beta release. In my opinion this is the current SNAPSHOT version. I would not perform a real beta release and publish it through all channels because I think this is a process overhead with how the release process currently goes. This includes votings on the mailing list and the verification of all release artifacts. I could think of an informal beta release where we simply change the mvn version number for a single deploy to give users a stable version to use. Or after 1,5 months we simply drop a mail to the user list to encourage users to try the current snapshot version.
WDYT?
Best Regards,
Christian
-----Original Message-----
From: Ramesh Reddy [mailto:rareddy@redhat.com]
Sent: Freitag, 9. Oktober 2015 23:05
To: dev@olingo.apache.org
Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Christian,
Thank you for reaching out to the broader community, I really appreciate it. In my experience #3 works as good policy for us in Teiid community. We release about every ~3 months (+/-2Wks). However, there are two rules we follow
1) At the beginning of the cycle, (or more towards the end of last cycle) we reach out to the community and look at current JIRAs and figure out what are the couple major features/enhancements we want to get done. These we label as "driving" factors for the release. These are must have features. Note that these could be computed from # votes received from community etc.
2) Fix ANY and ALL the bugs found in previous and current releases. Never "push" a "critical/major" bugs into another release unless there is clear workaround or alternative. Community really appreciates timely fixes of known bugs.
Then there may be internal requests team need to honor <wink>, and what contributors like me would want to contribute for supporting our community <wink>. And then there are best effort enhancements, that we could push to next/future releases if they did not get done in time.
At the beginning, we can set the target date for the release, and do a "beta" releases, after first month/month and half, depending upon the feature completions.
development = 0 - 1 1/2 months
beta = 1 1/2 - 2 1/2 months
CR/Release = 2 1/2 - 3 months
During this time, if you have the cadence, you can also do bug fix releases on the previous releases, depending upon the need.
WDYT?
Ramesh..
----- Original Message -----
> Hi all,
>
> Since we now have the first stable release with our 4.0.0 version I
> would like to start a discussion about the future release cycle of the
> V4 library. With the V2 library there have not been many people from
> the open source world involved so the Olingo members have been
> releasing if they thought it was a good idea. Communication about this
> was mostly done privately until the vote mail was send to the dev
> list. Even with the V4 beta releases there has not been a really clear
> path of what we hoped to get into the releases and when to release
> them.
>
> Since there are now more contributors I would like the Olingo
> community to get to a consensus about how we as an Apache project want
> to handle this in the future.
>
> 1. Should we define a feature set and log it inside JIRA. Then once
> this set is implemented a release is done.
> 2. Should we define a time cycle e.g. 1-3 months and provide releases
> even if some features are not ready.
> 3. A combination I could not yet think of
>
> WDYT?
>
> Best Regards,
> Christian
>
Re: [DISCUSS] Future Release cycle of the Olingo V4 library
Posted by Ramesh Reddy <ra...@redhat.com>.
Christian,
Thank you for reaching out to the broader community, I really appreciate it. In my experience #3 works as good policy for us in Teiid community. We release about every ~3 months (+/-2Wks). However, there are two rules we follow
1) At the beginning of the cycle, (or more towards the end of last cycle) we reach out to the community and look at current JIRAs and figure out what are the couple major features/enhancements we want to get done. These we label as "driving" factors for the release. These are must have features. Note that these could be computed from # votes received from community etc.
2) Fix ANY and ALL the bugs found in previous and current releases. Never "push" a "critical/major" bugs into another release unless there is clear workaround or alternative. Community really appreciates timely fixes of known bugs.
Then there may be internal requests team need to honor <wink>, and what contributors like me would want to contribute for supporting our community <wink>. And then there are best effort enhancements, that we could push to next/future releases if they did not get done in time.
At the beginning, we can set the target date for the release, and do a "beta" releases, after first month/month and half, depending upon the feature completions.
development = 0 - 1 1/2 months
beta = 1 1/2 - 2 1/2 months
CR/Release = 2 1/2 - 3 months
During this time, if you have the cadence, you can also do bug fix releases on the previous releases, depending upon the need.
WDYT?
Ramesh..
----- Original Message -----
> Hi all,
>
> Since we now have the first stable release with our 4.0.0 version I
> would like to start a discussion about the future release cycle of the
> V4 library. With the V2 library there have not been many people from
> the open source world involved so the Olingo members have been
> releasing if they thought it was a good idea. Communication about this
> was mostly done privately until the vote mail was send to the dev
> list. Even with the V4 beta releases there has not been a really clear
> path of what we hoped to get into the releases and when to release
> them.
>
> Since there are now more contributors I would like the Olingo
> community to get to a consensus about how we as an Apache project want
> to handle this in the future.
>
> 1. Should we define a feature set and log it inside JIRA. Then once
> this set is implemented a release is done.
> 2. Should we define a time cycle e.g. 1-3 months and provide releases
> even if some features are not ready.
> 3. A combination I could not yet think of
>
> WDYT?
>
> Best Regards,
> Christian
>