Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=691027 Michel Alexandre Salim <michel+fdr@xxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(michel+fdr@sylves | |tre.me) | --- Comment #13 from Michel Alexandre Salim <michel+fdr@xxxxxxxxxxxx> 2011-04-02 05:51:15 EDT --- Hi Hushan, I am not personally familiar with n2n, and I assume you are, so it's up to you. If you want to track the trunk branch, though, since it's not tagged 2.1.0 yet, you have to follow the guidelines for pre-release versions for the release tag: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} in this case it would be something like n2n-2.1.0-0.1.some-svn-tag here The packaging guideline recommends putting the date there, but I never see it stated as an explicit requirement. It probably dates back to CVS days where each file tracked in CVS has is own version number! I'd recommend also adding the SVN revision to this. See e.g. the nouveau driver: $ rpm -q xorg-x11-drv-nouveau xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.x86_64 ^ date ^ ^ commit ID ^ I'd recommend using the SVN revision number instead, so: git svn clone --no-minimize-url https://svn.ntop.org/svn/ntop/trunk/n2n/n2n_v2 git log -1 # show last commit -> Jan 31, revision 4444 # wow, that's not very auspicious in some culture's numerology! thus the N-V-R will be n2n-2.1.0-0.1.20110131svn4444%{?dist} by tracking trunk, you can just do a 'git svn rebase' to pull in later changes. When 2.1.0 is tagged, you can either do another 'git svn clone' for that tag, as described in the previous commit, or just, from within the Git clone, checkout the revision corresponding to the tag: git checkout $(git svn find-rev rXXXX) and then do the `git archive` as described before. The release tag for a released version will be of the normal form -- %{X}%{?dist} -- no need to include the SVN revision (but if, say, upstream has a branch for bugfixes that you're tracking, and release patches without bumping the release number, then it's like the pre-releases but without the '0.' prefix. A bit complicated, but whenever I see a Scala package on Maven, I shudder at their horrible versioning practice -- in Fedora we try to make sure a package's NVR is always monotonically increasing, allowing smooth upgrades (when that failed for some reason -- upstream renaming their release scheme, for instance, that's when you see packages with 'Epoch' numbers. Those are super-versions) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review