On Wed, Oct 7, 2015 at 12:14 PM, Till Westmann <[email protected]> wrote:
> On 7 Oct 2015, at 11:52, Preston Carman wrote: > > Remaining tasks: >> - Move to Java 1.8 >> > Works with out changes. :-) > - Move to Hyracks latest release (0.2.16) >> > I create a pull request in github for this change: https://github.com/apache/vxquery/pull/29 > - Reading HDFS files (GSOC project in review) > > >> Is there anything else you think should be included or left out? >> > > Sounds good to me. > > Side question: Is this the best place to define the next VXQuery release? >> How does JIRA fit into this process? >> > > Not sure how precisely we want to define a release. > But there a some things that we could do > > 1) I’ve just created 2 versions (05 - last one - and 0.6) in JIRA. So now > we can use the “Affects Version” field to indicate in which version an > issue was found and the “Fix Version” field to indicate in which version an > issue is fixed. For feature requests we could have different semantics for > “Affects Version”, but I fear that that could get confusing. > Adding versions to the tickets will be nice as move forward. > > 2) To target in issue for a release we could just add labels, e.g. > “0.6-target” for issues that should go into 0.6 and “0.6-blocker” for > issues that have to go into 0.6 (if any). That way we could easily > determine which issues are related to which (ongoing) release. Of course we > could also have separate labels like “0.6”, “target”, and “blocker” - I > don’t have a strong opinion either way. > I think adding tags such as “0.6-target” would work. Before the next release we can search for all issues with that tag to confirm they have been completed. > > Does this make sense? > Other thoughts/ideas? > > Cheers, > Till >
