search

dasmithii / Kit

project manager for c/c++
MIT License
65 stars 6 forks source link

Version tracking and differentiation #3

Open dasmithii opened 10 years ago

dasmithii commented 10 years ago

At this point, modules are treated identically regardless of their version. This poses a problem when library APIs change and undermine existing codebases.

TODO

dasmithii commented 10 years ago

Right now, modules are indexed by paths to their git repositories, so versions could probably be identified by commit hash. Any thoughts on that?

emanuelpalm commented 10 years ago

After skimming through the source code, I must see I'm quite impressed by how clean it is. Anyway.

Commit hashes is a great idea. If support could be added to check out modules based on tags, that would be even better. A lot of major open source projects use a vMAJOR.MINOR version scheme based on GIT tags, and they move the tags around as they fix bugs in legacy versions.

dasmithii commented 10 years ago

Yeah, I try to keep organized as much as possible.

Now, assuming dependencies are tagged with commit hashes or version numbers, how would conflicting includes be handled. Say v1.1 and v1.4 are indirectly required by a project, how could we handle symbol conflicts?

emanuelpalm commented 10 years ago

That was a harder nut to crack. ;) I don't know, actually.

Generate a warning and stick with the more recent version?

Another option could be to prompt the user and have him/her decide to include each dependency version, or just the most recent one. I don't like when I have to configure stuff more than needful, so I guess this option isn't preferred.

Giving tags any more treatment than simply allowing their use would increase complexity a lot, since we would have to second guess how people would use them. I don't believe a complex system around GIT tags is the way forward.