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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >> 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? >> >>> >> > >>
