Re: Cayenne release policy thoughts

[John Huss <jo...@gmail.com>]

Thanks Mike,

I wasn't aware of the specifics regard the review, so that is very helpful.
Are there instructions around for how to verify these things? With a
specific task list I can probably help with this more than I have before.

I would be in favor of shorter release cycles - 5 years is crazy. I have
always been using trunk/master versions because I started using Cayenne
during the 3.2 time frame, so the official releases don't matter much to
me. But it would be better to release more often.

Thanks,
John

On Sun, Apr 29, 2018 at 11:44 AM Mike Kienenberger <mk...@gmail.com>
wrote:

> All releases (no matter how they are named) must be reviewed by the
> PMC, but people often forget that the required elements of the review
> are licenses, signing and checksums, and source code.   The review
> process could be shorted to just these three easily-evaluated items.
>
> The voting period could be shorted as long as each PMC member has a
> chance to participate, but we have 3 PMC members who aren't currently
> active, so that might be more difficult to determine.
>
>
> On Sun, Apr 29, 2018 at 2:20 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >> We've typically never added a feature to a x.y release once it is
> final. But that doesn't have to be a hard and fast rule. For example, we
> could decide to release 4.0.1 with new features as long as no existing
> functionality is broken.
> >
> > I don't see a problem with that even under the current scheme. It is
> more of a cost/benefit thing to the core devs, so usually backporting is
> limited to bug fixes. I'd say in practice someone will need to lobby (or
> send a PR) for a feature X to be ported to an N - M release.
> >
> >> 2. Faster release cycle signifies project health
> >
> >
> > Yep.
> >
> >> 3. Separately versioned modeler
> >> If the modeler was able to save older versions of the schema, then
> there would be no need to maintain older branches for that app and it could
> move forward more quickly without maintenance of old branches.
> >
> > That's be great in theory, though in practice it will actually result in
> *more* maintenance and testing, as we'd need to handle the whole spectrum
> of (possibly conflicting) model capabilities in the same version of the
> tool. We may try to provide "Save as version N -M" option though. Not sure
> if that is a helpful scenario.
> >
> >> 4. More lightweight alpha releases
> >>
> >> To make it quick and easy to cut development milestones, can we skip
> the PMC voting process and go for something slightly less formal. Betas and
> release candidates would have the full review process. Or even just have an
> expedited 24 hour voting period.
> >
> > I don't think we can do this as an Apache project. All releases must be
> approved by the PMC, and there's no wiggle room on that. IIRC there was
> even pushback against posting direct CI links on the project website.
> >
> > Andrus
> >
> >
> >
> >
> >> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
> >>
> >> 1. More releases means more patching and releasing of bug fixes to
> different branches.
> >>
> >> To understand the impact of this we need to consider what a new release
> means and how many old releases we need to support.
> >>
> >> * API change
> >>
> >> * new features added
> >>
> >> * deprecated methods removed
> >>
> >> We've typically never added a feature to a x.y release once it is
> final. But that doesn't have to be a hard and fast rule. For example, we
> could decide to release 4.0.1 with new features as long as no existing
> functionality is broken. Or conversely we could call it 4.1, but no longer
> provide bug fixes for 4.0, requiring users to upgrade to get those fixes as
> long as that upgrade doesn't require the user to change any code in their
> app.
> >>
> >> So what is the balance between providing old bug fix releases and being
> able to move forward more quickly? saltstack is an example of a software
> project that adds new features from 2018.3.0 to 2018.3.1, but doesn't
> change existing functionality.
> >>
> >>
> >> 2. Faster release cycle signifies project health
> >>
> >> Developers will look at the number of releases per year as a
> measurement of project health. So more releases are a good thing.
> >>
> >>
> >> 3. Separately versioned modeler
> >>
> >> If the modeler was able to save older versions of the schema, then
> there would be no need to maintain older branches for that app and it could
> move forward more quickly without maintenance of old branches.
> >>
> >>
> >> 4. More lightweight alpha releases
> >>
> >> To make it quick and easy to cut development milestones, can we skip
> the PMC voting process and go for something slightly less formal. Betas and
> release candidates would have the full review process. Or even just have an
> expedited 24 hour voting period.
> >>
> >>
> >> Just a few thoughts. For our own projects we've been using milestone
> Cayenne releases in production for as long as I can remember, so I
> certainly like the idea of formalising them into shorter release cycles,
> particularly now that most of the disruptive (to users) changes in the API
> over the last years are probably behind us.
> >>
> >>
> >> Ari
> >>
> >>
> >>
> >> On 28/4/18 8:50pm, Nikita Timofeev wrote:
> >>> Hi all,
> >>>
> >>> Wanted to share my thoughts about our release policy.
> >>>
> >>> I think it will be better for Cayenne to reduce scopes of future
> >>> releases, as not many users are ready to use milestone or even beta
> >>> releases. At the same time we can't create final release if there are
> >>> a lot of new things, because of long feedback cycle.
> >>> Good example of this problem is 4.0 version that started 5 years ago
> >>> (as a 3.2 back then) and still not finished. Even Java itself released
> >>> faster now :)
> >>>
> >>> As for nearest plans, 4.1 already have some nice features (like
> >>> field-based data objects or recently added completely new dbimport
> >>> interface in Modeler), so I think we can target it to feature freeze
> >>> after M2.
> >>>
> >>> And we can already start to push new tasks into next (4.2?) version or
> >>> even think about several versions ahead.
> >>>
> >>> So any thoughts about overall shorter release cycles or 4.1, 4.2
> release plans?
> >>>
> >
>

Re: Cayenne release policy thoughts

[Nikita Timofeev <nt...@objectstyle.com>]

Here is a little summary of this thread:

1. New features:
Right now we make any global changes (public API, new logic, complex
bug fixes) only in feature releases, i.e. 4.0 or 4.1 can have this
changes, while 4.0.1 or 3.1.3 can't.
I think this is default policy understandable by all, so maybe we can
keep it this way.

2. Old features deprecation and removal:
Once again, currently we do not remove anything without deprecation
and can do this only in feature releases.
So we can deprecate something in 4.0 and remove in 4.1.

This policy is totally fine to me, but if we'll have shorter release
cycles, maybe we can rate each breaking change
and have separate policies based on severity of such change (e.g.
deprecation in cayenne-dbsync can't affect much users to keep it for
several releases).

3. Old release maintenance:
I don't know do we have any strict rules about this one, I try to
backport bug fixes to latest stable release, while no features are
added there.
This one is about maintenance cost vs user convenience. So I prefer
shorter list of old versions that we support, but I'm not a user :)
Once again we can rate each bug fix, and apply critical ones to older releases.

4. Release voting:
As we can't skip voting, we can make 72h voting for milestones
releases and longer (up to 7d as we have currently) for beta, RC and
final.
This one doesn't slow me personally down much, but still shorter is better :)

5. Separate modeler lifecycle:
I think this one is not immediate thing to do, but something we need
to keep in mind.

6. We need some global plans that is available to everyone.
This maybe simple issues list in Jira with special "fix version", or
dedicated page on website. But we need to have it, this will be good
for everyone.


So it will be really great if we can settle down on this and write it
down as a guideline for everyone.

On Thu, May 3, 2018 at 12:06 AM, Mike Kienenberger <mk...@gmail.com> wrote:
> Take a look at any of my release votes.  I only do the legal bare
> minimum when voting for a release in most cases.   Each of my votes
> gives the exact steps I take.
>
>
> On Wed, May 2, 2018 at 4:59 PM, John Huss <jo...@gmail.com> wrote:
>> Thanks Mike,
>>
>> I wasn't aware of the specifics regard the review, so that is very helpful.
>> Are there instructions around for how to verify these things? With a
>> specific task list I can probably help with this more than I have before.
>>
>> I would be in favor of shorter release cycles - 5 years is crazy. I have
>> always been using trunk/master versions because I started using Cayenne
>> during the 3.2 time frame, so the official releases don't matter much to
>> me. But it would be better to release more often.
>>
>> Thanks,
>> John
>>
>> On Sun, Apr 29, 2018 at 11:44 AM Mike Kienenberger <mk...@gmail.com>
>> wrote:
>>
>>> All releases (no matter how they are named) must be reviewed by the
>>> PMC, but people often forget that the required elements of the review
>>> are licenses, signing and checksums, and source code.   The review
>>> process could be shorted to just these three easily-evaluated items.
>>>
>>> The voting period could be shorted as long as each PMC member has a
>>> chance to participate, but we have 3 PMC members who aren't currently
>>> active, so that might be more difficult to determine.
>>>
>>>
>>> On Sun, Apr 29, 2018 at 2:20 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>> >> We've typically never added a feature to a x.y release once it is
>>> final. But that doesn't have to be a hard and fast rule. For example, we
>>> could decide to release 4.0.1 with new features as long as no existing
>>> functionality is broken.
>>> >
>>> > I don't see a problem with that even under the current scheme. It is
>>> more of a cost/benefit thing to the core devs, so usually backporting is
>>> limited to bug fixes. I'd say in practice someone will need to lobby (or
>>> send a PR) for a feature X to be ported to an N - M release.
>>> >
>>> >> 2. Faster release cycle signifies project health
>>> >
>>> >
>>> > Yep.
>>> >
>>> >> 3. Separately versioned modeler
>>> >> If the modeler was able to save older versions of the schema, then
>>> there would be no need to maintain older branches for that app and it could
>>> move forward more quickly without maintenance of old branches.
>>> >
>>> > That's be great in theory, though in practice it will actually result in
>>> *more* maintenance and testing, as we'd need to handle the whole spectrum
>>> of (possibly conflicting) model capabilities in the same version of the
>>> tool. We may try to provide "Save as version N -M" option though. Not sure
>>> if that is a helpful scenario.
>>> >
>>> >> 4. More lightweight alpha releases
>>> >>
>>> >> To make it quick and easy to cut development milestones, can we skip
>>> the PMC voting process and go for something slightly less formal. Betas and
>>> release candidates would have the full review process. Or even just have an
>>> expedited 24 hour voting period.
>>> >
>>> > I don't think we can do this as an Apache project. All releases must be
>>> approved by the PMC, and there's no wiggle room on that. IIRC there was
>>> even pushback against posting direct CI links on the project website.
>>> >
>>> > Andrus
>>> >
>>> >
>>> >
>>> >
>>> >> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis <ar...@maniatis.org>
>>> wrote:
>>> >>
>>> >> 1. More releases means more patching and releasing of bug fixes to
>>> different branches.
>>> >>
>>> >> To understand the impact of this we need to consider what a new release
>>> means and how many old releases we need to support.
>>> >>
>>> >> * API change
>>> >>
>>> >> * new features added
>>> >>
>>> >> * deprecated methods removed
>>> >>
>>> >> We've typically never added a feature to a x.y release once it is
>>> final. But that doesn't have to be a hard and fast rule. For example, we
>>> could decide to release 4.0.1 with new features as long as no existing
>>> functionality is broken. Or conversely we could call it 4.1, but no longer
>>> provide bug fixes for 4.0, requiring users to upgrade to get those fixes as
>>> long as that upgrade doesn't require the user to change any code in their
>>> app.
>>> >>
>>> >> So what is the balance between providing old bug fix releases and being
>>> able to move forward more quickly? saltstack is an example of a software
>>> project that adds new features from 2018.3.0 to 2018.3.1, but doesn't
>>> change existing functionality.
>>> >>
>>> >>
>>> >> 2. Faster release cycle signifies project health
>>> >>
>>> >> Developers will look at the number of releases per year as a
>>> measurement of project health. So more releases are a good thing.
>>> >>
>>> >>
>>> >> 3. Separately versioned modeler
>>> >>
>>> >> If the modeler was able to save older versions of the schema, then
>>> there would be no need to maintain older branches for that app and it could
>>> move forward more quickly without maintenance of old branches.
>>> >>
>>> >>
>>> >> 4. More lightweight alpha releases
>>> >>
>>> >> To make it quick and easy to cut development milestones, can we skip
>>> the PMC voting process and go for something slightly less formal. Betas and
>>> release candidates would have the full review process. Or even just have an
>>> expedited 24 hour voting period.
>>> >>
>>> >>
>>> >> Just a few thoughts. For our own projects we've been using milestone
>>> Cayenne releases in production for as long as I can remember, so I
>>> certainly like the idea of formalising them into shorter release cycles,
>>> particularly now that most of the disruptive (to users) changes in the API
>>> over the last years are probably behind us.
>>> >>
>>> >>
>>> >> Ari
>>> >>
>>> >>
>>> >>
>>> >> On 28/4/18 8:50pm, Nikita Timofeev wrote:
>>> >>> Hi all,
>>> >>>
>>> >>> Wanted to share my thoughts about our release policy.
>>> >>>
>>> >>> I think it will be better for Cayenne to reduce scopes of future
>>> >>> releases, as not many users are ready to use milestone or even beta
>>> >>> releases. At the same time we can't create final release if there are
>>> >>> a lot of new things, because of long feedback cycle.
>>> >>> Good example of this problem is 4.0 version that started 5 years ago
>>> >>> (as a 3.2 back then) and still not finished. Even Java itself released
>>> >>> faster now :)
>>> >>>
>>> >>> As for nearest plans, 4.1 already have some nice features (like
>>> >>> field-based data objects or recently added completely new dbimport
>>> >>> interface in Modeler), so I think we can target it to feature freeze
>>> >>> after M2.
>>> >>>
>>> >>> And we can already start to push new tasks into next (4.2?) version or
>>> >>> even think about several versions ahead.
>>> >>>
>>> >>> So any thoughts about overall shorter release cycles or 4.1, 4.2
>>> release plans?
>>> >>>
>>> >
>>>



-- 
Best regards,
Nikita Timofeev

Re: Cayenne release policy thoughts

[Mike Kienenberger <mk...@gmail.com>]

Take a look at any of my release votes.  I only do the legal bare
minimum when voting for a release in most cases.   Each of my votes
gives the exact steps I take.


On Wed, May 2, 2018 at 4:59 PM, John Huss <jo...@gmail.com> wrote:
> Thanks Mike,
>
> I wasn't aware of the specifics regard the review, so that is very helpful.
> Are there instructions around for how to verify these things? With a
> specific task list I can probably help with this more than I have before.
>
> I would be in favor of shorter release cycles - 5 years is crazy. I have
> always been using trunk/master versions because I started using Cayenne
> during the 3.2 time frame, so the official releases don't matter much to
> me. But it would be better to release more often.
>
> Thanks,
> John
>
> On Sun, Apr 29, 2018 at 11:44 AM Mike Kienenberger <mk...@gmail.com>
> wrote:
>
>> All releases (no matter how they are named) must be reviewed by the
>> PMC, but people often forget that the required elements of the review
>> are licenses, signing and checksums, and source code.   The review
>> process could be shorted to just these three easily-evaluated items.
>>
>> The voting period could be shorted as long as each PMC member has a
>> chance to participate, but we have 3 PMC members who aren't currently
>> active, so that might be more difficult to determine.
>>
>>
>> On Sun, Apr 29, 2018 at 2:20 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>> >> We've typically never added a feature to a x.y release once it is
>> final. But that doesn't have to be a hard and fast rule. For example, we
>> could decide to release 4.0.1 with new features as long as no existing
>> functionality is broken.
>> >
>> > I don't see a problem with that even under the current scheme. It is
>> more of a cost/benefit thing to the core devs, so usually backporting is
>> limited to bug fixes. I'd say in practice someone will need to lobby (or
>> send a PR) for a feature X to be ported to an N - M release.
>> >
>> >> 2. Faster release cycle signifies project health
>> >
>> >
>> > Yep.
>> >
>> >> 3. Separately versioned modeler
>> >> If the modeler was able to save older versions of the schema, then
>> there would be no need to maintain older branches for that app and it could
>> move forward more quickly without maintenance of old branches.
>> >
>> > That's be great in theory, though in practice it will actually result in
>> *more* maintenance and testing, as we'd need to handle the whole spectrum
>> of (possibly conflicting) model capabilities in the same version of the
>> tool. We may try to provide "Save as version N -M" option though. Not sure
>> if that is a helpful scenario.
>> >
>> >> 4. More lightweight alpha releases
>> >>
>> >> To make it quick and easy to cut development milestones, can we skip
>> the PMC voting process and go for something slightly less formal. Betas and
>> release candidates would have the full review process. Or even just have an
>> expedited 24 hour voting period.
>> >
>> > I don't think we can do this as an Apache project. All releases must be
>> approved by the PMC, and there's no wiggle room on that. IIRC there was
>> even pushback against posting direct CI links on the project website.
>> >
>> > Andrus
>> >
>> >
>> >
>> >
>> >> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis <ar...@maniatis.org>
>> wrote:
>> >>
>> >> 1. More releases means more patching and releasing of bug fixes to
>> different branches.
>> >>
>> >> To understand the impact of this we need to consider what a new release
>> means and how many old releases we need to support.
>> >>
>> >> * API change
>> >>
>> >> * new features added
>> >>
>> >> * deprecated methods removed
>> >>
>> >> We've typically never added a feature to a x.y release once it is
>> final. But that doesn't have to be a hard and fast rule. For example, we
>> could decide to release 4.0.1 with new features as long as no existing
>> functionality is broken. Or conversely we could call it 4.1, but no longer
>> provide bug fixes for 4.0, requiring users to upgrade to get those fixes as
>> long as that upgrade doesn't require the user to change any code in their
>> app.
>> >>
>> >> So what is the balance between providing old bug fix releases and being
>> able to move forward more quickly? saltstack is an example of a software
>> project that adds new features from 2018.3.0 to 2018.3.1, but doesn't
>> change existing functionality.
>> >>
>> >>
>> >> 2. Faster release cycle signifies project health
>> >>
>> >> Developers will look at the number of releases per year as a
>> measurement of project health. So more releases are a good thing.
>> >>
>> >>
>> >> 3. Separately versioned modeler
>> >>
>> >> If the modeler was able to save older versions of the schema, then
>> there would be no need to maintain older branches for that app and it could
>> move forward more quickly without maintenance of old branches.
>> >>
>> >>
>> >> 4. More lightweight alpha releases
>> >>
>> >> To make it quick and easy to cut development milestones, can we skip
>> the PMC voting process and go for something slightly less formal. Betas and
>> release candidates would have the full review process. Or even just have an
>> expedited 24 hour voting period.
>> >>
>> >>
>> >> Just a few thoughts. For our own projects we've been using milestone
>> Cayenne releases in production for as long as I can remember, so I
>> certainly like the idea of formalising them into shorter release cycles,
>> particularly now that most of the disruptive (to users) changes in the API
>> over the last years are probably behind us.
>> >>
>> >>
>> >> Ari
>> >>
>> >>
>> >>
>> >> On 28/4/18 8:50pm, Nikita Timofeev wrote:
>> >>> Hi all,
>> >>>
>> >>> Wanted to share my thoughts about our release policy.
>> >>>
>> >>> I think it will be better for Cayenne to reduce scopes of future
>> >>> releases, as not many users are ready to use milestone or even beta
>> >>> releases. At the same time we can't create final release if there are
>> >>> a lot of new things, because of long feedback cycle.
>> >>> Good example of this problem is 4.0 version that started 5 years ago
>> >>> (as a 3.2 back then) and still not finished. Even Java itself released
>> >>> faster now :)
>> >>>
>> >>> As for nearest plans, 4.1 already have some nice features (like
>> >>> field-based data objects or recently added completely new dbimport
>> >>> interface in Modeler), so I think we can target it to feature freeze
>> >>> after M2.
>> >>>
>> >>> And we can already start to push new tasks into next (4.2?) version or
>> >>> even think about several versions ahead.
>> >>>
>> >>> So any thoughts about overall shorter release cycles or 4.1, 4.2
>> release plans?
>> >>>
>> >
>>