3.3 Release Planning
Locked
 
|
Hi
In a few weeks I have time to work on making a Seaside 3.3 release. The only real big item that is still open is jQuery 3 and the jQuery split. Johan I know you were working on this and I assume you're very busy. Personally I don't view this as a blocker. I would be fine with doing a Seaside 3.3 release in October without jQuery 3 and a Seaside 3.4 release whenever jQuery 3 is ready. What are your opinions? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Sounds fine to me. I personally don't think that jQuery 3 is important
enough to postpone the release. On 3 Oct 2018, at 13:46, Philippe Marschall wrote: > Hi > > In a few weeks I have time to work on making a Seaside 3.3 release. > The only real big item that is still open is jQuery 3 and the jQuery > split. Johan I know you were working on this and I assume you're very > busy. Personally I don't view this as a blocker. I would be fine with > doing a Seaside 3.3 release in October without jQuery 3 and a Seaside > 3.4 release whenever jQuery 3 is ready. > What are your opinions? > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
The jQuery 3 changes should be ready to go. I’ll run over it today or tomorrow and commit.
For the split-off, I will do that in a branch and it should not block a release. Johan > On 3 Oct 2018, at 13:46, Philippe Marschall <[hidden email]> wrote: > > Hi > > In a few weeks I have time to work on making a Seaside 3.3 release. > The only real big item that is still open is jQuery 3 and the jQuery > split. Johan I know you were working on this and I assume you're very > busy. Personally I don't view this as a blocker. I would be fine with > doing a Seaside 3.3 release in October without jQuery 3 and a Seaside > 3.4 release whenever jQuery 3 is ready. > What are your opinions? > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
btw, this was done last week :)
The split will be something for after this release. ps: I think we should also no longer use a ‘dev’ branch but rather work with feature branches in the future and merge the changes in as soon as they are ready. > On 4 Oct 2018, at 07:43, Johan Brichau <[hidden email]> wrote: > > The jQuery 3 changes should be ready to go. I’ll run over it today or tomorrow and commit. > > For the split-off, I will do that in a branch and it should not block a release. > > Johan > >> On 3 Oct 2018, at 13:46, Philippe Marschall <[hidden email]> wrote: >> >> Hi >> >> In a few weeks I have time to work on making a Seaside 3.3 release. >> The only real big item that is still open is jQuery 3 and the jQuery >> split. Johan I know you were working on this and I assume you're very >> busy. Personally I don't view this as a blocker. I would be fine with >> doing a Seaside 3.3 release in October without jQuery 3 and a Seaside >> 3.4 release whenever jQuery 3 is ready. >> What are your opinions? >> >> Cheers >> Philippe >> _______________________________________________ >> seaside-dev mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Fri, Oct 12, 2018 at 9:19 AM Johan Brichau <[hidden email]> wrote:
> > btw, this was done last week :) > > The split will be something for after this release. > > ps: I think we should also no longer use a ‘dev’ branch but rather work with feature branches in the future and merge the changes in as soon as they are ready. 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. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
That works well for small, short lived branches with backwards 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) so we already establish the interface and we can tackle the rest of that refactoring for a next release. cheers Johan _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Fri, Oct 12, 2018 at 7:32 PM Johan Brichau <[hidden email]> 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 _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |