indygreg added a comment.
We can treat two requirements strings as equivalent. The trick is once we introduce a requirements string in the wild, we can't make BC changes to its format. i.e. the behavior surrounding a store requirement must be immutable over time. So e.g. if we introduce `narrowhg-experimental` today, any repos with that requirement will be openable by any Mercurial supporting that requirement, even if we change the store format. That's not good. Especially if we ship `narrowhg-experimental` with different behavior in say 4.6 and 4.7. One trick I like to do (which I'll be doing with the wire protocol shortly), is introduce a version component. e.g. `experimental-narrow-0001`. If you make a change to the format, you bump to `experimental-narrow-0002`. This basically requires that a specific revision of Mercurial must be used for all operations. When we finally make the transition to non-experimental, you can optionally teach new clients to treat the latest experimental version as equivalent to the final version. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2007 To: durin42, #hg-reviewers Cc: indygreg, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
