[mythtv-users] [mythtv] ANNOUNCEMENT: MythTV is moving to Github
mythtv-users at westbrook.com
Sat Dec 4 11:17:30 UTC 2010
On Sat, Dec 4, 2010 at 03:01, Gavin Hurlbut <gjhurlbu at gmail.com> wrote:
> That's not going to happen. We don't need thousands of pointless
> tags. Sorry. We can figure something out, but it won't be tagging
> every commit.
No apology necessary -- I don't really want it done that way either. Just
> Maybe you can prepend an increasing number before the
> hash. I dunno.
Having non-numerics anywhere in the version number breaks portage,
unfortunately. But you're helping me go down a good path.
It occurs to me to possibly refer to "the 253rd commit on the fixes/0.24
branch" with a sequential number (e.g. "mythtv-git-0.24.253"), and then just
look up the hash in that position in the git log to find the right commit to
pull. But then it occurs to me that git allows (I believe) for changes that
could break the assumption of such a sequence's reliability.
As an aside: I absolutely love MythTV's "-fixes" release process. It's
rapid and robust, and stands high above those of so many other community
projects. Unfortunately, it seems to confuse people who intuit that a
simpler version number is the better one to install. (I've actually
overheard someone saying 0.24 must be better than 0.24-fixes because the
latter "looks like a beta".) I usually rebuild packages two or three times
a week for the MythTV systems I manage, each time with improved goodness.
So, simple and unambiguous build versioning is important to me.
Anyway, my goal here is to adopt a package numbering nomenclature that works
numerically for me and package management systems like mine, but also has
consistent and unambiguous meaning outside my little world (especially if
I'm to share my ebuilds in the future, which I'd like to). Impossible
goal? I hope not!
I guess I'll keep scratching my head for a bit. Further thoughts
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users