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 c
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 wrote:
> Thanks Mike,
>
> I wasn't aware of the specifics regard the review, so that is ve
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.
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
> 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 curr
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
Hi Nikita,
I've thought similar for a while, but never brought it up.
At a minimum, a shorter release cycle would allow more release
announcements and give the appearance of a very active project. Cayenne is
stable and mature, so it isn't in a state of rapid development turmoil with
frequent rel
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
