+1 for fixed version Typical JIRA workflow would expect the Assignee to put fixed version AFTER the issue is resolved. There's another field 'Target Version' which is used for planning, however, in the interest of simplicity, we can use Fixed Version.
As for M2, we already have a lot of new features going-in (wan, cq, pulse, etc) so we could fix only high-priority items (POM, artifacts, etc) and remove any new items that haven't been started yet, and prepare for a release. +1 for Anil's proposal He brings-up an important question about release cadence - time or scope? My view is for a time-based release that creates an execution rhythm (release early/often). This would also utilize agile/ sprint mechanisms available in JIRA. How about 6 weeks of dev (feature, bug squashing, etc) and 2 weeks of release hardening (prep/review/vote)? May need a different thread than M2. Nitin On Fri, Mar 18, 2016 at 9:03 AM, Anilkumar Gingade <[email protected]> wrote: > +1 fixed version... > > About what we need to include, depends on time-line (if any) and scope of > the release (based on requirement)... > > If there is no time-line and there is no specific requirement, we can take > balanced approach...Have a release time (approximate); identify tickets > that can be fixed.... > > GEODE-1072 can be big chunk of work...Or most of sub-project in > GEODE-818... > > -Anil. > > > > On Thu, Mar 17, 2016 at 9:12 PM, Anthony Baker <[email protected]> wrote: > > > +1 for fix version > > > > Anthony > > > > > On Mar 17, 2016, at 8:55 PM, William Markito <[email protected]> > > wrote: > > > > > > +1 to use "Fix Version". This also helps with release notes > > auto-generated > > > by JIRA. > > > > > > About the scope, I'd push for M3 at least GEODE-33 and rather release > > > sooner... > > > > > > > > >> On Thu, Mar 17, 2016 at 5:31 PM, Dan Smith <[email protected]> wrote: > > >> > > >> Hi folks, > > >> > > >> We currently have 17 open M2 issues marked with "Sprint" M2, and 14 of > > >> those are also marked with "Fix Version" M2. Which of these issues do > we > > >> actually want to try to get into M2 at this point, and what do we want > > to > > >> push out? > > >> > > >> As far as tracking the issues go I think we should settle on a single > > >> convention: either the sprint field or the fix version field. What > > field do > > >> people want to use? > > >> > > >> M2 Wiki Page: > > >> > > >> > > > https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release > > >> > > >> Issues with M2 as the Sprint > > >> https://issues.apache.org/jira/issues/?filter=12334915 > > >> > > >> GEODE-27 Apache Geode POM file(s) are incorrect! > > >> GEODE-386 Change xsd namespace to apache > > >> GEODE-33 Create project examples > > >> GEODE-1075 GEODE-818 Move Admin REST API code into the geode-web > > >> project > > >> GEODE-1072 GEODE-818 Move HDFS code to it's own subproject and get > > rid > > >> of HDFS dependencies in gemfire-core > > >> GEODE-1080 GEODE-818 Move JettyHelper and related classes to a > > >> subproject > > >> GEODE-1074 GEODE-818 Move gfsh classes into their own sub project > > >> GEODE-1073 GEODE-818 Move redis to it's own sub-project, remove > > >> dependencies from core > > >> GEODE-818 RC Feedback: Fix Maven & pom dependencies > > >> GEODE-823 RC Feedback: Fix build artifacts > > >> GEODE-52 Remove @author tags from Java source > > >> GEODE-1071 GEODE-818 Remove MailManager and javax.mail dependency > > >> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, > > >> asc.sha1) > > >> GEODE-1025 Remove compile dependency on spring data gemfire/geode > > >> GEODE-914 Review NOTICE (again) > > >> GEODE-904 Update LICENSE for BSD/MIT dependencies > > >> GEODE-874 v1.0.0-incubating.M1.RC2: Text file errors in the source > > >> distribution > > >> > > >> -Dan > > > > > > > > > > > > -- > > > > > > ~/William > > >
