Overview
Request History
matejcik created request
new python macro definitions,
prerequisite for new python submission
licensedigger added legal-team as a reviewer
new_package: 1.0git.1483874658.ead0b0b
licensedigger accepted review
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added factory-repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
factory-repo-checker accepted review
Builds for repo devel:languages:python:Factory/openSUSE_Tumbleweed
maxlin_factory added openSUSE:Factory:Staging:adi:2 as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:2"
maxlin_factory accepted review
Picked openSUSE:Factory:Staging:adi:2
maxlin_factory set openSUSE:Factory:Staging:F as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:F"
maxlin_factory accepted review
Moved to openSUSE:Factory:Staging:F
babelworx accepted review
dimstar accepted review
dimstar_suse accepted review
ready to accept
dimstar_suse approved review
ready to accept
dimstar_suse accepted request
Accept to openSUSE:Factory
Not a decline reason, but I would have put a separator between 1.0 and git (either . if the commit is AFTER the 1.0 release, or ~ if it is BEFORE the 1.0 release)
good point. given that there is no "release" and the 1.0 is meaningless, i suppose i'll add a dot.
is 1.0.git > 1.0git, or do i have to bump the version too?
well if 1.0 is meaningless, then 0~ should be the identifier (it sorts really really low, just in case anyone ever starts some kind of versioning scheme).
1.0git == 1.0.git for rpm
meaning: you can add the dot without any fear and it will just work
thanks, i'll do that for next update.
(I suppose it should have been 0~, but istm there is no point in changing it now, future versioning schemes will simply have to be based off 1.0. Seeing as right now I'm the upstream, this seems safe to do.)