I think we can really see some process improvements as well! I've
been taking a look at github actions or bots that could perform
cherry-picks (if conflict-free, of course) or back-porting PRs, and
I've found a few interesting projects *close* to it, like
On fr 22 sep. 2023 18:40, Ryan Skraba wrote:
> Back to this topic :D After a couple of extra releases on the
> branch-1.11, how do we feel about supporting two major releases? Have
> committers found it a pain in the butt to cherry-pick?
>
Not a pain, but my process is not as clean as merging
Back to this topic :D After a couple of extra releases on the
branch-1.11, how do we feel about supporting two major releases? Have
committers found it a pain in the butt to cherry-pick?
Imagine if we were to release 1.12.0 tomorrow...
* master would be new features destined for 1.13.x
* we
On Wed, Aug 2, 2023 at 10:14 AM Oscar Westra van Holthe - Kind <
os...@westravanholthe.nl> wrote:
> Hi everyone,
>
> The proposal so task has much to offer that (at least in my opinion) is
> worth the extra effort of maintaining a third branch.
>
> I'm not certain if we should also add
Hi,
On Tue, Aug 1, 2023 at 9:13 PM Ryan Skraba wrote:
> Bringing this subject back while it's still a bit fresh :D
>
> For the moment we seem to agree... But does anybody have any
> objections _against_ maintaining two major version (by keeping the
> *three* branches ready to release)?
>
I
Hi everyone,
The proposal so task has much to offer that (at least in my opinion) is
worth the extra effort of maintaining a third branch.
I'm not certain if we should also add non-breaking changes to the last
maintenance release. Does this mean we release each branch separately when
ready, and
Bringing this subject back while it's still a bit fresh :D
For the moment we seem to agree... But does anybody have any
objections _against_ maintaining two major version (by keeping the
*three* branches ready to release)?
Playing the devil's advocate: it would be a bit more work to merge a
PR,
I think we're all agreeing so far! Let's say we release 1.12.0 today,
the state would be
master: 1.13.0-SNAPSHOT
branch-1.12: 1.12.1-SNAPSHOT
branch-1.11: 1.11.3-SNAPSHOT
We would attempt to keep all three of those in a releasable state, but
the moment we release 1.13.0, branch-1.11 drops off
I like Christophe's proposal !
On Tue, Jul 18, 2023 at 11:52 AM Christophe Le Saëc
wrote:
> Hello
> I find this proposal relevant.
>
> to clarify :
>
> > From 1.12.0 on, I'd like to propose maintaining *two* major versions
> > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and
Hello
I find this proposal relevant.
to clarify :
> From 1.12.0 on, I'd like to propose maintaining *two* major versions
> (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify
> APIs and give developers one whole major release to switch.
this means to maintain 3 branches
10 matches
Mail list logo
