Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove RecentFilesService from Engine #874

Closed
CharliePoole opened this issue Jan 20, 2021 · 6 comments · Fixed by #1131
Closed

Remove RecentFilesService from Engine #874

CharliePoole opened this issue Jan 20, 2021 · 6 comments · Fixed by #1131

Comments

@CharliePoole
Copy link
Contributor

In TestCentric/testcentric-gui#582 we agreed that both projects would remove RecentFiles from the engine as it has nothing special to do with running tests. This is a breaking change.

@CharliePoole
Copy link
Contributor Author

@ChrisMaddock @jnm2 @rprouse @mikkelbu @OsirisTerje

This is ready to go to a PR although I'm holding off for now until #896 is merged.

That means we're at a decision point, so I've tried to mention everyone who may be impacted.

If we treat this as a breaking change requiring a 4.0 release, merging it to master basically implies that there will be no more 3.x releases of the engine. That has been the plan, of course, but now it's time to be sure we are ready to commit to that.

Options...

  1. Merge to master and make the next release be 4.0

  2. Merge to master, but make the next release 3.13, treating this as non-breaking or at least not badly breaking.

  3. Merge but postpone the decision, which implies that (2) is acceptable as well as (1).

If we are going the route of (2), then I'll advance the version in the build script to 4.0 in addition to what I've done so far.

@rprouse
Copy link
Member

rprouse commented Feb 9, 2021

In the framework, I made a v3.13 branch in case we need to do bug fix releases before I made any breaking changes. I could have branched off the release tag in the future, but I thought it was more explicit and will keep a 3.13 dev branch available if we need to do multiple releases and more work.

Should we do the same here and prepare for 4.0?

@ChrisMaddock
Copy link
Member

This should be in 4.0 in my opinion.

My plan was to create a 4.0 branch and leave 3.13 as the master, merging 4.0 changes into the 4.0 branch, and eventually into master. So essentially the same as Rob's, but with a different default.

We already have a bunch of non-breaking changes merged into master for 3.13 - I think it might be wise to keep the breaking ones separate for the time being, as we're not really clear on how long 4.0 will take. How do we feel about a separate 4.0 branch, and merging master into it now and again? Probably makes sense to merge in the 'big' PRs like the copyright header change before we create this branch.

Charlie - if everyone agrees, would you mind setting this up with your PR? As it looks this this will be the first 4.0-specific PR!

@CharliePoole
Copy link
Contributor Author

Marked as blocked by #896

@CharliePoole
Copy link
Contributor Author

Merged into the 4.0 branch

@CharliePoole
Copy link
Contributor Author

This was merged to dev-4.0 and closed. I'm reopening it so as to replicate it in main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants