ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Pai <>
Subject Re: Ivy - Proposal for reviving the project and moving towards a release
Date Wed, 14 Dec 2016 04:11:02 GMT
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.


On Monday, December 12, 2016, Maarten Coene <>
> 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 <>
>  Aan:
>  Verzonden: zondag 11 december 15:22 2016
>  Onderwerp: Ivy - Proposal for reviving the project and moving towards a
> 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
> 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
> 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]
> [2]
> [3]
> -Jaikiran
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message