Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-19982

Blog: Rename Github Repository's to reflect eZ Publish 5 structure

    Details

    • Sprint:
      Stetind Sprint 4

      Description

      This story needs implementation spec, and a final vote in engineering and community.

      Current proposal that has most favor is:

      • ezp-next -> ezpublish-api
      • ezpublish -> ezpublish-legacy
      • ezpublish5 -> ezpublish

      A couple of problems exist with this proposal:

      • links to all repo's will break (but current consensus is that it will be worth it long term)
        • Note: We could send a request to github about possibility of setting up redirects, if that is possible, then maybe "ezpublish5" should be renamed "ezpublish-standard" or similarly to reflect it is a meta/build repository
      • ezpublish-api is not a good name as it contains so many other things as well
        • We could consider splitting up ezp-next into "-api" (including spi), "-core", "-core-bundle" and "-legacy-bundle", benefits would be clearer separation between what is what, even though "-core" would still contain lots of different stuff not strictly related to each other.

        Issue Links

          Activity

          Hide
          Edi Modrić (Inactive) added a comment -

          > links to all repo's will break (but current consensus is that it will be worth it long term)

          Not just links to repos. As I've already mentioned on mailing list, it could possibly ruin repos for people that are unaware of the change.

          > We could consider splitting up ezp-next into "-api" (including spi), "-core", "-core-bundle" and "-legacy-bundle", benefits would be clearer separation between what is > what, even though "-core" would still contain lots of different stuff not strictly related to each other.

          This potentially leads to lots of headaches in later maintenance. Also, what about commit history? I'd rather keep all of it together and find a different suitable name than loosing all of commit history if we split it up. There are ways to retain commit history, but they're not really straightforward.

          Show
          Edi Modrić (Inactive) added a comment - > links to all repo's will break (but current consensus is that it will be worth it long term) Not just links to repos. As I've already mentioned on mailing list, it could possibly ruin repos for people that are unaware of the change. > We could consider splitting up ezp-next into "-api" (including spi), "-core", "-core-bundle" and "-legacy-bundle", benefits would be clearer separation between what is > what, even though "-core" would still contain lots of different stuff not strictly related to each other. This potentially leads to lots of headaches in later maintenance. Also, what about commit history? I'd rather keep all of it together and find a different suitable name than loosing all of commit history if we split it up. There are ways to retain commit history, but they're not really straightforward.
          Hide
          André Rømcke added a comment -

          > Not just links to repos. As I've already mentioned on mailing list, it could possibly ruin repos for people that are unaware of the change.

          Rather a break now on this then forever having issue with people using the wrong repo.

          > This potentially leads to lots of headaches in later maintenance.

          This is true, the more we split, the more work it is to do changes across different repos.
          It comes down to two things, if we have a need to separate stuff, like bundles, and where we draw the line.

          > Also, what about commit history?

          Commit history is not an issue, git has powerful commands to split out certain parts of a repository history, as long as proper "git mv" has been used on move operations earlier paths should be part of that as well.

          Show
          André Rømcke added a comment - > Not just links to repos. As I've already mentioned on mailing list, it could possibly ruin repos for people that are unaware of the change. Rather a break now on this then forever having issue with people using the wrong repo. > This potentially leads to lots of headaches in later maintenance. This is true, the more we split, the more work it is to do changes across different repos. It comes down to two things, if we have a need to separate stuff, like bundles, and where we draw the line. > Also, what about commit history? Commit history is not an issue, git has powerful commands to split out certain parts of a repository history, as long as proper "git mv" has been used on move operations earlier paths should be part of that as well.
          Hide
          Edi Modrić (Inactive) added a comment - - edited

          > This is true, the more we split, the more work it is to do changes across different repos.
          > It comes down to two things, if we have a need to separate stuff, like bundles, and where we draw the line.

          Have you considered ezpublish-kernel?

          After all, everything in current ezp-next is kernel in one way or another. Core/Legacy/REST bundles, API, SPI...

          Or, the following can be done:

          ezp-next -> ezpublish
          ezpublish -> ezpublish-legacy (or even ezpublish4)
          ezpublish5 - leave it as it is, since this repo is a symfony app and when ezpublish 6 comes out, new meta repo, ezpublish6, could be created

          Show
          Edi Modrić (Inactive) added a comment - - edited > This is true, the more we split, the more work it is to do changes across different repos. > It comes down to two things, if we have a need to separate stuff, like bundles, and where we draw the line. Have you considered ezpublish-kernel? After all, everything in current ezp-next is kernel in one way or another. Core/Legacy/REST bundles, API, SPI... Or, the following can be done: ezp-next -> ezpublish ezpublish -> ezpublish-legacy (or even ezpublish4) ezpublish5 - leave it as it is, since this repo is a symfony app and when ezpublish 6 comes out, new meta repo, ezpublish6, could be created
          Hide
          Bertrand Dunogier added a comment - - edited

          After careful dev-team discussion:

          before after
          ezpublish ezpublish-legacy
          ezp-next ezpublish-kernel
          ezpublish5 ezpublish-community
          Show
          Bertrand Dunogier added a comment - - edited After careful dev-team discussion: before after ezpublish ezpublish-legacy ezp-next ezpublish-kernel ezpublish5 ezpublish-community
          Hide
          Edi Modrić (Inactive) added a comment -

          Looking good to me.

          +1

          Show
          Edi Modrić (Inactive) added a comment - Looking good to me. +1
          Show
          André Rømcke added a comment - Blog post available for review at: https://docs.google.com/a/ez.no/document/d/17JmbxtRY5LOqBXyqlQoMBOhWV-TdeUfg62Y8v9Rka1s/edit Pull requests from Patric to be applied when change is done: https://github.com/ezsystems/ezpublish/pull/547 https://github.com/ezsystems/ezp-next/pull/209 https://github.com/ezsystems/ezpublish5/pull/32
          Hide
          Paulo Nunes (Inactive) added a comment -

          No QA Needed

          Show
          Paulo Nunes (Inactive) added a comment - No QA Needed

            People

            • Assignee:
              Unassigned
              Reporter:
              André Rømcke
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 6 hours, 7 minutes Time Not Required
                6h 7m

                  Agile