Move this repo to original dashboard repo (eXist-db/dashboard)

[joewiz]

From eXist-db/exist#2408 (comment):

If the new Dashboard is final, why don't we just import the code into the old repo. Git will save everything for us so we can always go back...

See also #13 (comment).

[JoernT]

while i agree that less repos are better i'm not sure if that doesn't lead to confusion. E.g. what to do with the existing tickets in the old one that do not apply to the new one? I don't really like the idea that i'm the one to sort these out.

further - we now got these distinct ones and would then suddenly mix them up. that can certainly cause some confusion. However why not drop the old repo once we're done and mark it deprecated?

I'm not against renaming this repo if the 'existdb-' the the offending factor in the name.

[dizzzz]

it is not the repo, it is the deployment URL?

[duncdrum]

@JoernT I really like the idea that whoever wrote the old dashboard code should also be the one to sort out the issues and PRs in that repo. Irrespective of the question if these two get merged or not.

[joewiz]

I propose the following plan to merge the repos, which I am happy to shepherd if we refine it and agree on the approach:

1. Prepare version numbers

• The old dashboard's version number is "1.1.0". We will prepare one more release incrementing the version to "1.1.1," with the primary change being setting its semver-max for eXist compatibility to "4.99.0"—so as to effectively limit the installation to eXist 4.x and avoid people in the 4.x branch carrying the old dashboard forward to 5.0.0. (It would still be possible, of course; folks would just need to create a custom build).
• The new dashboard's version number is "1.2.2". We will prepare a new release, advancing the version to "2.0.0" to signify the major change to the app, with the primary changes being (1) setting its semver-min for eXist compatibility to "5.0.0"—to limit the installation of the app to 5.x—to prevent the 4.x installer from bundling the new version, and (2) changing the package name (URI) to be the same as the 1.x series of the dashboard, so that the old & new versions' packages are grouped together when we publish 2.0.0 to the public-repo.

2. Sort out issues/PRs

• Review issues/PRs in old repo, with an eye toward closing issues that won't be fixed and noting any that remain with a "dashboard-1.x" label.
• Move still-open issues in the new repo over to the old repo.

3. Merge git repos

• The old dashboard's "master" branch will be renamed as "dashboard-1.x", to facilitate work on hotfixes to the old version should any be necessary.
• The new dashboard's "master" branch will be migrated to the old dashboard's repo, as "master".
• The new dashboard's original repo will be archived.

4. Publish 1.1.1 and 2.0.0 to public-repo

• Publish dashboard-1.1.1.xar and dashboard-2.0.0.xar to the public-repo
• Delete previous releases of "existdb-dashboard" to prevent confusion.

Result

• One repo, "dashboard"
• One app, "dashboard"
• One package URI, http://exist-db.org/apps/dashboard
• Two versions: 1.x for legacy (in its own branch for hotfixes), 2.x for new (occupying the master branch)
• Leverage EXPath package's dependency/@semver-min|max attributes to keep dashboard 1.x in eXist 4 and dashboard 2.x in eXist 5.
• Few or no remaining issues/PR for 1.x, with development and support clearly focused on 2.x

Thoughts?

[joewiz]

As described in task 2 above, I've completed a review of all outstanding issues and PRs in the original repo. I've also submitted a PR adding the "move" bot to this repo (#17); once that's moved I'll migrate this repo's 3 open issues to the original repo.

I've added an item to the agenda for Monday's community call to discuss my proposal. @JoernT Would you be able to join the call? If not, would you please add your comments here beforehand?

[adamretter]

To be clear. Let's not move the repo, instead we should bring in the git history atop the other repo. In this way we have the history of both repositories

[joewiz]

That’s what I mean - thanks for clarifying!

[joewiz]

I've now finished moving the remaining open issues to the old dashboard repository.

@wolfgangmm Am I right to assume there's no objection to the plan outlined above? If so, I'll proceed with steps 1, 3, and 4. (I'll take care to tread carefully around eXist-db/exist#2449 until that is fixed.)

[ghost]

This issue was moved by joewiz to eXist-db/dashboard#81.