Developing v5.5.0 alongside v5.4.1

[Jermolene]

If the development of v5.4.0 has reminded us of anything it is the importance of giving enough time for thorough testing. With that in mind, I think we should start merging PRs for v5.5.0 now, before any future v5.4.1 bug fix release.

With that in mind, I have prepared the master branch for v5.5.0 by updating the banner and the release note. Visitors to https://tiddlywiki.com/rerelease will therefore see v5.5.0

The question now is how we'll handle the inevitable v5.4.1 release. My idea was to create a new branch and PR for v5.4.x bug fix releases. We would then merge any bug fixes to that branch rather than to master. We would then use the Netlify preview for testing the release. This approach means that the v5.4.1 prerelease will have a longer URL such as https://deploy-preview-9999--tiddlywiki-previews.netlify.app/.

UPDATE: I should have added that we would use git merge v5.4.x to propagate bug fixes into master.

The plan makes sense if v5.4.1 because consists solely of targeted bug fixes that will be straightforward to test. However, the plan would fall apart if we wanted to include more substantial new features in v5.4.1 or v5.4.2.

UPDATE: We'll need criteria for what will be merged to the 5.4.x branch. For example, just translations, regressions and bug fixes, with new features or API changes going to master.

I would welcome thoughts or suggestions. For the moment we will hold off from merging to master.

[pmario]

IMO it may be easier to

• use master for v5.4.1 prerelease and
• use v5.5.0 as a dev train for the next version.

So we can

• merge new stuff into v5.5.0 and
• use master for bugfixes
• If the v5.4.1 is out we can merge it to v5.5.0 and then
  • when we are sure no v5.4.2 is needed
• merge v5.5.0 into master again.

Just an idea. Not sure if that's possible. git is a bit of a mystery for me too.

[Jermolene]

• when we are sure no v5.4.2 is needed

That is where it gets tricky. If it were to later turn out that v5.4.2 is required, we would be in exactly the same position as I outlined.

[Jermolene]

I've added a couple of clarifications to the OP.

[pmario]

I did hope, that this time we gave the community enough time to test.

I did expect some troubles, because of the backwards incompatible changes we intended. This time we did get more feedback than ever.

But as always ... The devil is in the details. I did run a new audit on deprecated.js and there are some more small differences / edge cases.

PR with detailed info is on the way. Currently I do need to do more testing.

[buggyj]

I do not like this idea,
this will mean that the next release with be on a bug fix branch instead of master,
the pre-release will not longer be pre-release, making testing harder for the community,
this changes more than 10 years of use of git for tiddlywiki and so will be confusing.

With v5.4.0 I did periodic check my plugins during its development, they were working, however, i did not test well enough and it was not obvious when a problem was introduced. On the one hand I want to contribute to tw development, but on the other hand I find testing boring. I feel that if the pre-release is not the next release I am LESS likely to test it with my plugins.

[pmario]

Currently master publishes to tw-com/prerelease. IMO that can stay that way.

If we have a v5.5.0 branch we can easily push new stuff to that one, till we are sure master is "safe" again.

IMO creating PRs against master, tiddlywiki-com (the docs channel) or v5.5.0 does not make the development process any harder than it is at the moment.

---

IMO it has been almost silent at Talk: Announcing the release of TiddlyWiki v5.4.0 and here too.

IMO all of the v5.4.0 open regression issues at GH have corresponding PRs, that should fix them. They need to be reviewed, tested and merged, to master.

Then we could release v5.4.1 after we got a new splash screen image.

[Jermolene]

On reflection, there will be fewer changes to infrastructure if we keep master as v5.4.1, and have a separate branch for v5.5.0. Changes are in a603146

[dongrentianyu]

I think there are other ways to make plugins that are required for version 5.5.0, so that users and developers who are willing to test version 5.5.0 can use this plugin and keep fixing it. This plugin will have a version number, which means fixing certain features. But the plugin needs to be configured so that only those features are allowed to be added in version 5.5.0, only those features are allowed to be tested and fixed, and new fusion will be made in the future if necessary. This brings convenience to different developers, and fast developers like @linonetwo can push features better.

[linonetwo]

Oops, I didn't understand what you were saying?