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)? Does this make
sense? 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?
Then these tarballs needs to be uploaded somewhere.
I don't see why this step is needed though, and why it has to involve
the dockapps.git repo.
It's related to the needs of packaging, right?
Why not do it internally and not involve the repo at all? I mean, the
purpose of the repository is to hold the source code. Everybody can
download it, create tarballs from the directories and keep a record
of what changed, and do whatever is needed with them.
It seems the real question here is who will make releases... Packagers
usually expect developers/maintaners to make releases and only package
what's released while Carlos seems to prefer that this task would be taken
on by packagers (as he is happy with the latest git and does not care
about releases). But this cannot be done by distros individually because
unless there's and agreement on what constitutes a release there will only
be incoherent snapshots made by packagers. It's better if developers make
the decision of when and what to release (which can just be a tag added to
the repository with a version number) and then packagers can continue to
integrate that into their distros. This decision cannot be made by the
individual packagers and must be done by the maintainer of the code repo.
That's why it involves the repo and its maintainer.
If you need to know the versions easily, then what I could do to
help is to have the versions in the dir names. But I can foresee that
those names will seldom change (if at all) because there's just not
too much going on.
Putting the versions in the dir name seems to be fragile and too easy to
forget to change them when they need to be released. It seems like this
would be a workaround for something else that's needed here, like tags on
individual apps or separate repos for them with their own tags if tagging
apps within the same repo is not possible.
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?
Regards,
BALATON Zoltan
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
