When it comes to version numbers, I'm more concerned about following semantic versioning than whether or not it's a major release. Bugfixes warrant micro version updates, while new features warrant minor version updates (and backward incompatible API changes are for the major version).
On 14 December 2016 at 05:47, Oulds, Jonathan <jonathan.ou...@intel.com> wrote: > I'd like to add my vote for a 2.4.1 release. We don't want to raise the > expectation that there will be substantial new functionality (which would > warrant a 2.5.0 version). > > However, if the 2.4.1 release goes well I would certainly suggest that we > aim for a 2.5.0 release in the second half of 2017. > > Longer term I would suggest that we try to maintain a regular release > schedule ideally two per year as below: > Q1 - Bug fix: > Q3 - Bug fix plus at least one new feature: > > > > Jonathan Oulds > Snr. Software Engineer > McAfee > > > -----Original Message----- > From: J Pai [mailto:jai.forums2...@gmail.com] > Sent: Wednesday, December 14, 2016 4:11 AM > To: Ant Developers List <dev@ant.apache.org>; Maarten Coene < > maarten_co...@yahoo.com> > Subject: Re: Ivy - Proposal for reviving the project and moving towards a > release > > Maarten, thanks for volunteering to review the PRs. One of them has a test > case. I will add a test for the other one. > > It looks like you have been involved with Ivy development and releases > before, so I think you would be in a better position to decide if it should > be 2.5.0 or 2.4.1. I personally prefer 2.4.1 because we are focussing on > fixing some reported issues rather than introducing some new features. > > As for the release timeline, the reason I asked for a March 2017 date is > to make sure we have a realistic goal in mind of releasing it instead of a > open ended one which drags can potentially drag on for a while given the > current state of the project. Having said that, you and others in ant-dev > team who have been involved in previous releases can decide what makes > sense in terms of release commitments. My whole goal is to try and get a > usable bug fix release out soon, since the last one was 2 years back. > > -Jaikiran > > On Monday, December 12, 2016, Maarten Coene <maarten_co...@yahoo.com. > invalid> > wrote: > > Thanks Jaikran, > > I will look at your patches, I'll try to do it this week.If possible, > please attach a junit test as well to reproduce the problem. > > > > About the release, the master branch already contains some fixes since > the 2.4.0 release. They are listed in the release-notes.html in the 'doc' > directory. If we want to create a 2.4.1 release, we should merge all these > changes (and all upcomming patches) into the 2.4.x branch as well. If we > decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't > pin on an exact timing, we can create a release any time when we think the > codebase is ready for it. > > > > We also have to find a release manager. I did it in the past when we > > were > on SVN, but I don't have enough GIT knowledge (and I don't have the time > to look into it) to do a new release. > > > > Maarten > > > > Van: Jaikiran Pai <jai.forums2...@gmail.com> > > Aan: dev@ant.apache.org > > Verzonden: zondag 11 december 15:22 2016 > > Onderwerp: Ivy - Proposal for reviving the project and moving towards > > a > release > > > > First off, I'm not an Ivy or Ant committer. The proposal that I make > > below for an Ivy release is based on what was discussed in a recent > > mail thread about the future of Ivy > > https://www.mail-archive.com/dev@ant.apache.org/msg45078.html. There > > was a suggestion that someone from community volunteer to try and > > bring in some activity into the project and see if we can create a > > release after triaging the JIRA issues. > > > > > > I have had a look at the open issues in JIRA today and decided to > > filter out issues that are open, updated since Jan 2014 and affects > > versions 2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter > > criteria to just select a few that I thought can be considered > > "active". This [1] returns 57 issues. I went ahead and looked at those > > issues today and have asked for more information in the JIRAs wherever > > relevant and have sent a couple of pull requests [2] [3] to fix some > straightforward ones. > > I also have another PR that I opened this week to fix one other issue. > > Out of those 57 issues, many are no longer relevant or don't have > > enough details. I don't have JIRA privileges to label them, share > > filters or even assign some to myself to track them better. So I think > > for now, we can rely on that JIRA search query [1]. > > > > At this point, I think, if we can target March 2017 for releasing a > > 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a > > good start. Some of the issues noted in that JIRA are indeed important > > ones and would need some review/help in fixing them correctly, which > > essentially means, we need at least one person who has had experience > > with the Ivy code and its design details and also has the committer > rights. > > > > > > Does any of this look feasible? Let me know if this isn't enough to > > move things forward - I don't want to end up sending PRs and spending > > time on this if there's no way we can get to a proper release in the > > next few months. > > > > > > [1] > > > https://issues.apache.org/jira/browse/IVY-1553?jql= > project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20% > 22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1. > 0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND% > 20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC > > > > [2] https://github.com/apache/ant-ivy/pull/11 > > > > [3] https://github.com/apache/ant-ivy/pull/12 > > > > -Jaikiran > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > > > > > > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- Matt Sicker <boa...@gmail.com>