follow history through release renames #35

Closed
muldis opened this Issue Dec 16, 2009 · 6 comments

Projects

None yet

2 participants

@muldis
muldis commented Dec 16, 2009

Sometimes a module is renamed, and its distribution is renamed accordingly. It would be useful to be able to mark that a pair of distributions with different base names are in fact versions of the same project, and so a module's history is followed through all the names it had. Separately, but probably more difficult, is following when distributions have been split up or combined, in that sometimes a particular module is bundled with others and other times it is released on its own. Both of these cases have happened with my projects.

@schwern
Contributor
schwern commented Dec 16, 2009

I agree about following renames. Its easy to do... if we knew what the renames were. It will have to be handled on a case-by-case basis as people spot the renames. Report them as issues as you spot them.

Tracking project splits and merges is more complicated. One example is Net-FTP vs libnet. I don't know how to make sense of that in terms of github.

@muldis
muldis commented Dec 16, 2009

I agree about the case-by-case, and expected this is probably how it would need to work. I was raising the issue more to say it needed doing, not how.

So to start off here are connections between my most recent projects, simpler version:

  • project 1 was named Muldis-DB for versions 0.0.0-0.6.2, then Muldis-Rosetta for versions 0.7.0 - present (0.15.0)
  • project 2 was named Language-MuldisD for versions 0.3.0-0.23.0, then Muldis-D for versions 0.24.0 - present (0.102.0)

More complicated version as a delta:

  • Language-MuldisD was split from Muldis-DB; version 0.2.0 was their last pre-split and versions 0.3.0 were each of their first post-split
@schwern
Contributor
schwern commented Jan 8, 2010

Another issue with this. Let's say Foo-Bar becomes Bar-Baz. What happens to the existing github repository? Do we rename it and leave the existing users (not to mention historical searches) in the lurch? Maybe one can be a mirror of the other?

@muldis
muldis commented Jan 8, 2010

Speaking for myself with my original repositories, if I rename the project I rename the repository, which Github supports. Its still the same project, and arguably people should be able to find it most easily using its current name. This is contrasted with a fork, where you'd want both, since a fork didn't occur. As for historical searches, if a search can be done on content and not just the name, then presumably the content will mention the old name a lot and it would be found that way. Speaking for myself, when a rename occurs, my "Changes" file still has a record of prior names, though generally no other files mention the old name.

@muldis
muldis commented Jan 8, 2010

In other words, I suggest just rename the repository and be done with it. No complication of mirroring. A search on the old name should still be able to find it under the new name.

@schwern schwern added this to the Pre-launch 2.0 milestone Aug 14, 2014
@schwern
Contributor
schwern commented Oct 6, 2014

This can be accomplished using backpan_normalize_dist_names and backpan_normalize_releases in .gitpan. I'll leave untangling the Muldis history for someone to tackle.

@schwern schwern closed this Oct 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment