On Thu, 4 Apr 2013 at 19:34:08 +0200, BALATON Zoltan wrote: > On Thu, 4 Apr 2013, Carlos R. Mafra wrote: > >>Step zero is to add tags to the repo. Without tags you will get > >>different results each time you call git-archive. > > > >Ok, I will do that, "dockapps v1.0". Is that acceptable? > > Does that mean that a change in say wmbiff will increase the version > number of all other dockapps (which also means they need to be > repackaged and updated in all distros while they are still the > same)?
No, no, not at all. My view is that the dockapps inside dockapps.git are _not_ individual entities anymore. Forget about wmbiff version 2.3 or whatever, there's only wmbiff v3.0 (or any other number higher than 2.12...) that is associated to the repo in which it resides. Just like drivers inside the linux kernel tree. People do not refer to driver foobar version X.Y but to the "driver foobar from the kernel 3.8". Everybody knows precisely what's meant by that and it's simple. If one particular driver didn't change during one particular release cycle, what's the problem? The alternative is to have thousands of repos and thousands of driver versions. There _is_ a huge advantage in keeping things together and releasing them together. We should do the same here. These dockapps were mostly dead tarballs hidden somewhere, no maintainer no nothing. Why do we have to care about historic version numbers for them? It's time to move on and change. Let's refer to them as v3.0 collectively, it's much simpler. I tag the repo v3.0 and that's it. If wmbiff changes and no other dockapp changes, who cares if all of them become v3.1 one year later? It's the repo that's moving, not the individual dockapps. I'm oversimplifying, but the filesystem 'ext2' keeps moving together with the whole kernel for every release even tough it might not have taken any patch. > Why not tag individual apps separately when they > are changed. They could still be managed in one repo but tagged by > their own independent versions tracking their own changes. Is that > possible with git? The problem happens when people consider the dockapps there individually and want to keep track of them individually. If you do that, it doesn't make sense to have them all in one repository in the first place and the difficulties pointed in this thread are related to trying to solve the wrong problem. And when you have the wrong problem to solve, no matter what you do it won't be the correct solution. > The problem seems to come from the grouping of independent apps into > one repo while their versions and release cycle cannot be > synchronised so despite of the common repo it should be kept > separate. Is this possible? Yes, I agree with you. The solution is to treat them together or split them into 40 different repos. I think the "kernel viewpoint" makes sense because it makes things simpler to manage. But it requires a small change in our mindset. The other solution is to split the repo. But in this case I don't want to be the maintainer of 40 different repos, that's too much for me. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
