[Seaside-dev] 3.3 Release Planning

[Philippe Marschall]

On Fri, Oct 12, 2018 at 7:32 PM Johan Brichau <johan at inceptive.be> wrote:
>
>
> That works well for small, short lived branches with backwards
> compatible changes. With filetree with metadata I often found out that
> merge conflicts quickly become too complex for even the merge driver
> to handle.
> And sometimes we want to introduce breaking changes that require a
> minor version increase.
>
>
> The inverse problem is that all features are now on the dev branch, and can only be released when they are all ready to go.
> The dev branch was in such a state for more than a year… I even merged changes from master to dev but I had no idea what the end-goal of the changes to dev were…

That's a fair point. We can always introduce a dev branch again should
we need it.

> Of course, the usual checklist for releasing applies.
> The changes per release are just smaller and more frequent.
>
> Another example: I might have the time to work on the jQuery split-off in a couple of weeks or so. Why not release 3.4 with only that feature? Version numbers are cheap ;)

I would be fine with that.

> In the meantime, I don’t want to stall releasing 3.3 and all the changes that people can use.
>
> Anyway…on to the real stuff: :)
> About this release: regarding the thisContext change: I’ll only add the AbstractContinuation package (https://github.com/SeasideSt/Seaside/issues/1007) so we already establish the interface and we can tackle the rest of that refactoring for a next release.

Awesome, thank you.

Cheers
Philippe