[Seaside-dev] 3.3 Release Planning

[Johan Brichau]

> 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…

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 ;)
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 <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.

cheers
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20181012/79b8076e/attachment.html>