Re: IvyDE status

[Stefan Bodewig]

On 2016-12-13, Gintautas Grigelionis wrote:

> Thanks for clarification. There are lots of duplications around there, and
> the overall process would surely benefit from some restructuring. I took
> the liberty of extracting the commits particular to style subdirectory
> (there are three of them, identical in ivy/source and ivyde/source trees).
> I would happily push them to Github if I had a permission to
> https://github.com/apache/any-ivy-site-styles, otherwise you may follow
> this procedure

github is a read-only mirror of repos hosted at the ASF, even the
Ant/Ivy committers can't directly push there.

https://github.com/apache/ant-ivy-site-styles is a very curious case as
it claims to mirror a repository that doesn't exist (I wanted to
manually push the svn files there but fail to find the repository).

It would be good if anybody could ask INFRA in order to figure out what
exactly the repo is mirroring as I don't see anything matching at
https://git-wip-us.apache.org/repos/asf - I'll do so myself at the
weekend, if nobody else finds time before that.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - Proposal for reviving the project and moving towards a release

[Stefan Bodewig]

On 2016-12-14, Matt Sicker wrote:

> 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).

I'm not sure how Ivy has decided on its version numbers in the past, but
for Ant we've never followed semantic versioning that strictly. In
particular we've created lots of micro releases that contained new
features and most of the time created minor versions when we changed JDK
requirements. In a sense we've shifted semantic versioning to the right
and never created major releases (and neither pure bugfix releases),
maybe because Ant2 could bring up some ghosts of the far past. :-)

As much as I like semantic versioning (and use it in other projects),
I'd prefer to stay consistent with the way versions have been used in
prior releases.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - Proposal for reviving the project and moving towards a release

[Matt Sicker]

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 
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 ; 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  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 
> >  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
> > 

RE: Ivy - Proposal for reviving the project and moving towards a release

[Oulds, Jonathan]

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 ; Maarten Coene 

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 
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 
>  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]
>