Skip to content
Snippets Groups Projects
Commit 74fb1842f8b9 authored by Pierre-Yves David's avatar Pierre-Yves David :octopus:
Browse files

phase: rename the requirement for internal-phase (BC)

The previous requirements covers both `internal` and `archived` phase.  However,
the `archived` phase is not ready for usage (while the internal one is mostly
ready for years). So we split the archived on in a dedicated requirements (see
previous changeset for details) and rename the one for internal-phase. This will
avoid older client trying to use the archived phase on `internal` only
repositories.

Since the requirements stayed experimental since its introduction. It seems
fine to drop the previous version.
parent 0c70d888a484
No related branches found
No related tags found
Loading
Loading
  • Developer

    This change is causing us a great deal of consternation. As we've been migrating to internal-phase for the past ~2 mo, we're now reliant on format.internal-phase and also internal-phase as the name of the requirement. Moreover, these new names, particularly internal-phase-2, is debt-ridden and ugly. Can we consider simply reverting this change?

  • Jason R. Coombs @jaraco

    mentioned in commit d9f88448f8c8

    ·

    mentioned in commit d9f88448f8c8

    Toggle commit list
  • Jason R. Coombs @jaraco

    mentioned in merge request !230 (closed)

    ·

    mentioned in merge request !230 (closed)

    Toggle commit list
  • Author Owner

    These changes are important to be able to get internal phase out of experimental in the short term. I'm afraid that some of the fundamentals can't really go away. Mostly, if the requirements name wouldn't change, newer clients could create (on disk) repositories on which older clients could end up using the archived phase "by mistake" by accessing the very same files. The name change prevents that by gating to new clients that will understand the requirement as "use the internal phase only".

    The new name can be different if people have strong feelings about it, maybe internal-phase-only? phase-internal?).

    That being said, the goal is obviously not to cause you trouble and we should see what can be done here. For example, some config aliasing and some extra patches to automatically migrate the old requirement to the new one might be enough to ease the transition on your side. What do you think?

  • Developer

    Mostly, if the requirements name wouldn't change, newer clients could create (on disk) repositories on which older clients could end up using the archived phase "by mistake" by accessing the very same files.

    I'd gotten the impression that the re-use of internal-phase for archive was an oversight and sparingly used and additionally protected by the cleanup-as-archived config. It seemed unlikely to me that someone would have cleanup-as-archive enabled, but internal-phase not (the one condition where older clients would end up using the archived phase).

    On the other hand, as you observed, the internal phase feature for shelve was fairly established. It was functional with just a few ux bugs (list, patch). In my opinion, it's far better potentially to break the archived feature than the more stable internal-phase. I realize now I maybe should have started with proposing to make internal-phase non-experimental before investing in it.

    Perhaps we could take this approach:

    1. Roll back internal-phase-2.
    2. While internal-phase is still experimental, if cleanup-as-archived is enabled but internal-phase is not and exp-archived-phase is not, warn that the user should disable cleanup-as-archived or enable exp-archived-phase.
    3. Make internal-phase non-experimental.
    4. After the warning above has had sufficient time to disseminate (1 yr?), enable internal-phase by default.

    This approach would cause a lot less disruption for repos that have already adopted the internal-phase for shelves, including designs and rollouts around this feature.

    I acknowledge that my proposal isn't completely safe. Someone with an old repo in the right configuration could miss the warning and end up with archived activated unintentionally.

    What about if instead of (3) and (4), jump straight to enabling internal-phase shelves by default? That is, start honoring internal-phase shelves without the requirement. Would that be possible?

    The new name can be different if people have strong feelings about it, maybe internal-phase-only? phase-internal?).

    Or maybe internal-phase-shelves or internal-phase-proper.

    For example, some config aliasing and some extra patches to automatically migrate the old requirement to the new one might be enough to ease the transition on your side. What do you think?

    We can probably manage that. The biggest uncertainty is around repos that already inherited the internal-phase requirement. Since this requirement no longer exists, I suspect those repos will become invalid, so it'll be important to remove internal-phase and replace it with internal-phase-{next}.

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment