More structured Release Process

Projects Core Development
1

I propose we start making releases more often, specially focused on actual bugfixes and security updates versus feature updates.

Currently, for example RC 1.4 has a mix of Bug Fixes, New Features, Changed Features and back ports in it:
https://github.com/ClassicPress/ClassicPress/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.4.0-rc1

This means, at current pace, and as of current progress in said milestone, it will be September 2022 until we release it (that is the time it took to release CP 1.3: one year, see Releases · ClassicPress/ClassicPress · GitHub).

That is not good. It means, bugs stay in the product for a year, when they are already fixed (or back ported), merged and tested.

A bug fix should never wait for a feature that is unrelated to it. Neither a security release.

I suggest we do this:

  1. 1.4 Milestone can stay as is but only with new features, and other things new/changing behaviour that are not bugs or security issues, thus not important.
  2. However, a (or several) new Milestone should be made, 1.3.x, with the goal to release within weeks, fixes for known bugs and security issues if any.
  3. Eventually, RC 1.4 should be split even more, to produce release of “done things” that are simply just waiting for more complex things to finish, which however are completely unrelated. Like, we have a finished few features, lets test, release and publish. Not wait for this thing that are unrelated, stuck, and clearly will need more time.

This approach should be taken throughout any future development process, by clearly making a Milestone more small, targeted and on topic, separating the bugs from features, where possible.
Not only will this speed up fix time, feature release time, but also make testing easier, smaller and less risky to break a whole CMS, as well as make updating much easier.

If we continue with the current process not only will we spend too much time on a single milestone/release but actual annoying bugs wont get fixed/released just because we can’t agree on a left-justification of a login screen or on the name of a new argument in a function (these are examples, but real ones)

I would suggest starting now with this, meaning all bugs from Pull requests · ClassicPress/ClassicPress · GitHub should get into a new, dedicated Milestone, if this is possible, and released preferably within the coming weeks
Since all current bugs in rc 1.4 are already solved, this should be possible without big hassle.

We can then fiddle and discuss on new features or other changes for milestone on the long run without discharging our disagreements on the actual users, who are waiting for bug fixes, trust CP to be safe, and new features that clearly are finished and ready to go.

Does that make sense to everybody?
I am not asking for scheduled releases, I am asking to actually allow things that are done and ready to be shipped, and bugs to be fixed when they are fixed, not to be waiting for a year on some feature that in the end, no one really cares about (again looking at the left aligned strings, which will hold us for probably the next few months at least, until we have an agreement, at which point we might start coding, which will take another few months :slight_smile: )

2 Likes
2

Yes, this sounds good.

3

Although possibly a minor point. From the viewpoint of visitors and potential new CP users the project will seem much more alive if “latest release” is only a week or two previously rather than last year.

2 Likes
4

Since CP follows semver.org, security fixes and bug fixes already do fall under Patch number 1.3.x.

I think it would be beneficial to see a list of issues slated for 1.4.0 that you think should make it to 1.3.x.

1 Like
5

Agreed, this would help if you could put together a list you believe should be released as part of 1.3.x.

For the rest, I am happy to bump anything that isn’t currently reviewed. That would leave 13 pending items. @Core_Committers thoughts?

I also don’t really believe this is a petition. This is more of a discussion about what should be included in releases and how much. I am not really sure how we would “close” this petition or “plan” it for the future. Are we okay to move this out?

1 Like
6

I’ve linked them in the main comment already, see above.

Current milestone > tag “bug” is what for sure should be part of a (coming soon) point release

7

For me fine, sure!

1 Like
8

You mean this link then:
https://github.com/ClassicPress/ClassicPress/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.4.0-rc1+label%3Abug

These are backports from WP so I think they should go with 1.4.x not as a patch to 1.3.x.

1 Like
9

Not really.

Bugs shouldn’t wait for features and are no features, this means they can and should be in a bug releases, and those are x.x.Y releases, not x.Y.x releases.

Those issues are tagged as bugs, so if they are no bug fixes the tag is wrong, and if they are bug fixes the tag allows for a point release 1.3.1

Honestly, I do not really care if we release 1.3.1, 1.4.0 or 7.0.0

What I care about, is that the bugs and security issues do not wait very long time (estimate one year) for some features that we plan to add, and since those (bugs and release) are currently all in the same milestone that is exactly what will happen.
Especially, if the PRs are basically done, just waiting for review + testing, we shouldn’t let them wait.

Even so for actual features, no one complains if we add useful Feature XY in a release, but we lose people if we wait one year for pushing a release with 2 tiny new features.

Back to bugs…the current bugs that are ready for testing, and should thus be released asap, are exactly the ones you linked: Pull requests · ClassicPress/ClassicPress · GitHub

Those are bugs, and I do not understand why they need to wait for things like these here Add 4 new attributes to paginate_links by smileBeda · Pull Request #792 · ClassicPress/ClassicPress · GitHub, or Revise login page link layout by johnalarcon · Pull Request #795 · ClassicPress/ClassicPress · GitHub.

Wether they are back ports or brand own code fixes, does not matter at all.
What matters is what they do: Fix things, Feature Add or BreakIng change.

I am sure there are more tickets in the milestone that could be part of a (quicker) point release, but those 4 are perfect candidates imo, that should not wait for (whichever it is) next “long term” version.

It boils down to “bugs and security should not wait for features”

10

OK now I think you are already working on changing the milestone, since above tickets disappeared from it :stuck_out_tongue:

So I would consider we can close this here?

(apart from the semantic discussion wether to use 1.3.1 or 1.4.0 which for me really will not matter, I am perfectly fine with anything coming, as long the bugs we already fixed are free to fly :D)

Thanks…

11

I think the one year thing was an anomaly. A pandemic reduced contributions and the major tool used in the build process went away.

2 Likes
12

Definitely we had more releases in 2020 and before, yes.

Yet still if we mix (perhaps bigger) unfinished things and make other, ready things wait for it, it’ll slow down development

Also because covid is all but over, at least from
What I see it is rather getting worse again, and we don’t necessarily have much more work power than we did before.

I mean, we do have some momentum, but I believe we shouldn’t stall one thing due to unfinished other thing
Better separate and release what’s ready - it also makes testing much easier! And keeps users seeing we are active.

…

Out of curiosity- what is the major tool that went away?
I wasn’t around prior to 2021 so… I don’t know what we used before which was faster / empowered for faster dev…

13

If I have understood, what went away is Travis and it was switched to GitHub Actions in the middle of the pandemic? but I wasn’t so present during that period so I can be mistaken.

1 Like
14

First off I agree with you that 1.3.0 took too long to come out. We had some growing pains as a project and as an organization.

It won’t take another year - literally right now we are starting a bug scrub in Slack with the aim of merging multiple of those open PRs.

Other than that, I am very happy to say that we have picked up a lot of momentum in the past few months. I would expect 1.4.0 to be out at the very latest by the end of October.

You are also missing something that is pretty important, which is the time that it takes to ship a release. This is multiple hours of work that only a couple of people can do, and honestly, it’s not justified to ship a new patch release every time there is a bugfix.

If you want to get bugfixes as soon as they are merged to the develop branch then I suggest you switch your site(s) to a nightly build. They have automatic updates also. You can find the nightly builds here: Releases · ClassyBot/ClassicPress-nightly · GitHub

You can use the migration plugin to switch an existing ClassicPress site to any of those “Source code (zip)” links on that page. (Note that if it’s a WordPress site then you will need to use one of the builds marked “migration”, the ones marked “nightly” won’t work for that.)

5 Likes
15

I see a difference between these two. I agree that security updates need to be pushed out asap. Bugfixes (provided they aren’t too annoying or damaging) can be on a slower cycle.

1 Like
16

It won’t take another year - […] 1.4.0 to be out at the very latest by the end of October.

Well that is great, and much better than I “feared”

You are also missing something that is pretty important, which is the time that it takes to ship a release. This is multiple hours of work that only a couple of people can do, and honestly, it’s not justified to ship a new patch release every time there is a bugfix.

I don’t miss that point, I am well aware of it, it is one of the reasons I ask to adopt best practices early.
Best practices IMO encompass that after a release, a “bug fix” milestone is created, and all bugs will get “added” to that bug fix release, while another milestone created for features, will hold feature requests.

This not only allows to fix bugs eventually introduced in the last release quickly and before eventual new features are ready but also take off time and effort from the devs, testers and translators or documenters, because usually bug fixes do not hold new strings (or rarely do), do not ask for new documentation, and as for testing just need to be tested for the specific fixed bug, while new features tend to affect an entire ecosystem of code, and thus need broader work.

If you want to get bugfixes as soon as they are merged to the develop branch then I suggest you switch your site(s) to a nightly build.

I do not think nightly builds are intended to fix bugs, I think they are intended to ship bleeding edge things, for testers, courageous users, and avid “pioneers”.

Lets assume CP would have the number of users that has been expected (read it in some post on this very site) in 2020: one million users. We wouldn’t want one million users to be waiting for the feature a couple ask for, just to get a couple annoying bug fixes.

Concluding, it is great that we estimate the 1.4 in October. Really great. What I ask for is to adopt best practices (I think widely accepted best practices, as I have seen in major companies all do that) early:

  • try to put bug fixes in actual bug release
  • try to offset features into actual feature releases

This will not only satisfy our users, increase the “livelihood” of CP but also take off workload on each release as outlined above. Yes, it adds a process to actually release, but considering the work it takes away from each release or better, thru focussing on specific things for the releases allows for a more streamlined and focused work, I believe that the “allover invested time” of our current approach of just making a milestone that asks for new features by default, is higher than making targeted milestones trying to separated bug/security from features.

If anything, maybe we can try that after 1.4 is out?
To immediately create a milestone 1.4.1 that will bundle (maybe new) bugs, and a milestone 1.5 that is the next feature release?

2 Likes
17

Yes, this sounds good as a next step, as well as keeping an eye on this process going forward, with the longer-term goal of having a more organized and predictable release cadence.

I agree that this will be increasingly important for “devs, testers and translators or documenters” to know what to expect as we continue growing.

6 Likes
18