Andrew McIntyre wrote:
So, I think tracking snapshots while development is occurring, but
merging them to the release version for searching purposes to keep
things tidy is the way to go. Once there's an official release, we're
not likely to see any bug reports against snapshots so I'm not sure
there's any need to track them past an official release.
For Fix version I think this is very clear. Developers always mark the
lowest fix version as sysinfo reports it and release notes for releases
are correct, users when looking for fixes know exactly what version they
can pick up to get the fix.
For Affects Version, it might be a little confusing for folks reporting
bugs because the version showed by sysinfo might be gone, but it is
good practice to verify against the latest release on the branch before
filing a bug anyway, so I think its ok.
For historical tracking past the release, really only the svn # is all
that interesting, but it certainly would be helpful if the svn
revision of the change was more integrated with Jira and you could
query Jira for things like what fixes went in in a certain svn range etc.
All that said, I think it would be good to make sure we do the right
thing here and make sure we are not blowing away versions that might be
needed.
I can't think of why they would be needed, but I have not done a
thorough analysis. Before you punch in merge it might be good to send
out a summary of the new process and a final "going, going..." message
to anyone who might see value in keeping this history.
BTW, Deepa, I would say just put a comment in DERBY-1005 for now about
the fix version being wrong.
Kathey
