Indeed versions are the most important metadata; I'd like to hear the thoughts of others.
1. Fix Version(s) We have only two options: Milestone or Label. One important difference between them is that an issue can have only one milestone but multiple labels. The other difference would be that while Milestone is special metadata, labels are just flexible text tags for searching. I'm personally fine with Milestone and my reasoning is that - we don't release a bug fix or improvement in multiple versions anyway. We don't have two CHANGES entries for one issue; if we resolve an issue in "10.0.0" and "9.3.0" the CHANGES entry appears only in Lucene 9.3.0's section. However I don't have a strong opinion on it and go with others' suggestions - should we continue to support multiple "fixed versions" with labels (tags)? 2. Affects Version(s) I have never used this metadata field but I'm perfectly fine with supporting this with labels if we need it. Tomoko 2022年6月20日(月) 18:40 Shai Erera <[email protected]>: > > Can we support "Affects Versions" with a label too? "affectsVersion: 8.x"? > > Regarding Fix Versions, don't we have multiple of these sometimes? E.g. a bug > fix may go into "8.1", "9.x" and "main"? Is it OK if we just drop support for > this? > > On Mon, Jun 20, 2022 at 12:33 PM Tomoko Uchida <[email protected]> > wrote: >> >> Hello all. >> >> Besides whether the migration of existing issues should be done or not >> (we still do not reach an agreement on it), I started to play around >> with GitHub issue metadata with a test repository. >> >> The current migration plan in my mind: >> >> * Issue Type -> Supported with labels (e.g. "type:bug"); it also can >> be attached when opening issues with issue templates. >> * Issue Priority -> Not supported. >> * Affects Versions -> Not supported. >> * Components -> Supported with labels (e.g.: "module:core"). >> * Resolution -> Not supported. >> * Fix Version(s) -> Partially supported with Milestone; an issue can >> have only one milestone - I'm fine with it. >> >> As you may see I'm going to drop the most of metadata that is >> supported in Jira for the sake of brevity. If you have objections or >> other perspectives, could you please speak up. >> >> Tomoko >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
