Opened 18 years ago
Last modified 18 years ago
#124 new enhancement
report patch version
Reported by: | diane | Owned by: | diane |
---|---|---|---|
Priority: | minor | Milestone: | release_1.2 |
Component: | core | Version: | |
Keywords: | Cc: |
Description
Brandon suggested that it'd be useful for mussa to have some version number... perhaps the count of darcs patches?
Though there's a problem with that in that its relative to a particular darcs repository.
Change History (8)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Milestone: | Few Small Repairs → document_1.0 |
---|
I'm cheating and going to say "version number" is an enhancement that's not technically required for this release. (So I'm going to move it to the documentation release). This may be just so I can, at least once make a deadline.
comment:3 by , 18 years ago
Milestone: | document_1.0 → release_1.0 |
---|
comment:4 by , 18 years ago
This is really hard to do right with darcs & cmake. It's far easier to just make a manual version number, or perhaps include the build user/host/date-time.
comment:5 by , 18 years ago
Milestone: | release_1.0 → Standing on our heads |
---|
I'm not going to fix this for this release... moving to a later milestone.
comment:6 by , 18 years ago
Milestone: | Standing on our heads → release_1.1 |
---|
comment:7 by , 18 years ago
A very different solution to this would be store the darcs changelog in the distributed app, and then add a webcall that could compare that list of patches with the current list on darcs and report how many patches behind the running version is. (Heck it could even let you browse the patches).
comment:8 by , 18 years ago
The ultimate in cool once you have the ability to store the darcs xml-patches you could submit that with your bug report. With that data, it should be possible to provide some darcs tool to pull just the patches from that xml file so the developers could test that exact version. (Excluding issues from dependencies.)
See changeset:420 for useful python script.