>> What about all the forks? Many people provide their modules as a git >> repository and people fork them and start hacking their own changes. >> With the linear model of version numbers we don't have any possibility >> to differentiate between a module foo that have been forked from 2.0 >> and >> evolved to 2.1 and the original module that might have been improved >> to >> version 2.1 . If you look at the current reality there are plenty of >> such modules. >> >> For sure the main goal to fix that is the common modules project, >> however if we introduce a formal description which modules work >> together >> or require another in a certain version we should be able to >> distinguish >> forks as well. Otherwise we might end up with a lot of people who take >> module foo from x in version 1, which requires module bar in version >> 2.1 >> but instead to take the actual version from x they take the fork >> from y. >> So somehow we need to be able to the actual version. > > Any suggestions for this?
Not really. We would need something like a unique identifier to which we could refer. On the other side it might be sufficient to mention the refered module with source in the README and if people mix that up... > I haven't been worrying too much about parallel versions in forks > because 1) I'm assuming that people will only ever have a single > version installed at a time and 2) Puppet can only deal with a single > module with a given name, so there isn't much opportunity for conflict. more or less yeah, but for example if I look to all the apache modules out there for example I think that quite everyone is completely different. > In the end, we can only usefully talk about dependencies within a > subset of modules that exist, and my assumption is that we'll > generally have two subsets we operate on: The modules installed, and > the modules available in whatever repositories we're looking at. It > should be straightforward to manage forks (or not support them) within > that subset. that should be fine. > That being said, I'm happy to find a solution here, but I'm not sure > it fits under the "simplest solution that provides a benefit", which > is what I was shooting for initially. I don't think it have to be in the very first version and I think we should start without this issue. But I think some time we should try to find a good solution for it. cheers pete --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
