jlaska: wwoods: did you have any thoughts on that autoqa.spec bump patch? wwoods: I feel like if the code changes, the version number should change wwoods: but other than that it's totally fine jlaska: wwoods: how do you mean, like the .spec should change anytime there is a change in master? jlaska: when I say, the .spec, I mean the %{release} in the autoqa.spec wwoods: obviously the release number has to change whenever we need to build a new RPM wwoods: the question is whether we should be bumping the autoqa version number when we're, say, adding new features / tests / etc. jlaska: wwoods: oh, gotcha, I see now wwoods: because, I mean, now we have two autoqa-0.3 tarballs wwoods: with different code wwoods: seems like we might want 0.3.1, 0.3.2, etc. wwoods: move to 0.4.0 when we make major/incompatible changes wwoods: since the RPM is the only way we really distribute autoqa it's not a big deal that we only change the release number wwoods: but it's a little confusing to me jlaska: wwoods: so technically, a %{release} change is when we're adding a patch against the tarball? jlaska: thus leaving the tarball untouched wwoods: that's the standard packaging procedure, yes wwoods: it's really bad practice to have multiple tarballs with the same filename but different contents jlaska: wwoods: gotcha. This is sort of odd for us since we are upstream ... carrying patches against the tarball probably isn't something we'd ever do? wwoods: right. so it makes more sense to just update the tarball jlaska: alrighty ... I can make those changes to the patch wwoods: possibly increasing the version number wwoods: or possible doing the standard git snapshot procedure jlaska: so to summarize, instead of going to autoqa-0.3-4 we should change to autoqa-0.3.1-1 ? wwoods: in my opinion, yes jlaska: wwoods: cool, no objections here ... just want to get this puppy packaged :) wwoods: like I said we could also do the git snapshot thing wwoods: but that's kind of annoying jlaska: I never really got into the grove of having the %{version} match a git/cvs tag or timestamp jlaska: yeah, same ... it was kind of annoying wwoods: and since we're upstream and can tag new versions whenever we want wwoods: let's just tag a new version whenever we want a new tarball * jlaska will be tagging this in git once we iron out the version jlaska: okay jlaska: wwoods: okay, thanks for feedback ... I'll rev the patch and resubmit to the list wwoods: jlaska: cool, thanks