cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Cayenne release policy thoughts
Date Wed, 02 May 2018 21:06:35 GMT
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 <johnthuss@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 <mkienenb@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 <andrus@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 <ari@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?
>> >>>
>> >
>>

Mime
View raw message