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

[ghost]

@joewiz commented on Jan 21, 2019, 11:19 AM UTC:

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).

This issue was moved by joewiz from eXist-db/existdb-dashboard#15.

[ghost]

@JoernT commented on Jan 21, 2019, 1:44 PM UTC:

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.

[ghost]

@dizzzz commented on Jan 21, 2019, 2:01 PM UTC:

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

[ghost]

@duncdrum commented on Jan 21, 2019, 2:04 PM UTC:

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.

[ghost]

@joewiz commented on Jan 23, 2019, 5:45 AM UTC:

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?

[ghost]

@joewiz commented on Jan 26, 2019, 9:08 PM UTC:

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?

[ghost]

@adamretter commented on Jan 27, 2019, 2:03 AM UTC:

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

[ghost]

@joewiz commented on Jan 27, 2019, 4:08 AM UTC:

That’s what I mean - thanks for clarifying!

[ghost]

@joewiz commented on Feb 1, 2019, 2:42 AM UTC:

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.)

[joewiz]

Okay, I have now completed the remaining actions we decided on here:

• v1.1.1 (requires < eXist 5.0) and v2.0.0 (requires >= eXist 5.0.0-RC7) have been tested and released
• both versions share the same EXPath package name and abbrev
• the history of commits to the existdb-dashboard repo has been migrated here
• the existdb-dashboard repo has been retired
• the releases of existdb-dashboard have been removed from the public-repo

I haven't migrated/adapted tags from the existdb-dashboard repo yet, since permissions on the repo are preventing me from pushing tags to branches, but if we do so, we need to avoid duplicating the original repository's tags, e.g., by making each missing tag 2.0.0-RC1, 2, 3, etc.

[duncdrum]

looking at dashboard 2.0.0 in 5.0.0-Snapshot i see the following console errors in Safari 12.0.3

[Error] Failed to load resource: the server responded with a status of 404 (Document /db/apps/dashboard/bower_components/webcomponentsjs/webcomponents-hi.js.map not found) (webcomponents-hi.js.map, line 0)
[Error] Failed to load resource: the server responded with a status of 404 (Document /db/apps/dashboard/resources/icon.svg not found) (icon.svg, line 0)

[joewiz]

The work proposed above is complete. Please open new issues for any follow-on problems.