| Re: [egit-dev] Re: A 0.7.2 release? |
Right. Also I think we want to avoid including non-committer code in a service release because its not listed in an IP log for the project.
So, right now I don't see a good reason to bother with a new service release. The only thing we would pick up is Eclipse 3.4 compatibility. That might be a bug fix but is it important enough to the project? Remember that creating a release requires having Chris do some black magic voodoo to copy the artifacts from Hudson over to the download servers. That isn't free and has a real time cost for him.
Right now I know of at least 3 if not 4 major bugs in the pack handling code of 0.7.1. I would rather see us get these fixed before we declare a service release. I'm hoping to be able to work on those this week, but we all know how best laid plans tend to get ruined by reality... :-(
On Apr 11, 2010 4:34 PM, "Chris Aniszczyk" <caniszczyk@xxxxxxxxx> wrote:
> On Sun, Apr 11, 2010 at 6:30 PM, Matthias Sohn
> <matthias.sohn@xxxxxxxxxxxxxx> wrote:
>> According to [1] changes which are externally visible (as far as I
>> understand this would include new features) should increment
>> the minor segment of the version number, increasing only the service segment
>> is reserved for internal changes like bug fixes etc.
>> I am also not sure if it is ok to publish a new release containing new
>> features without passing another formal release review
>> including IP check and the usual paperwork.
>> [1] http://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment
>
> We are allowed to release minor releases without going through a
> release review. It's simply up to us.
>
> We should only be doing something like major bug fixes in a minor
> point release like suggested.
>
> --
> Cheers,
>
> Chris Aniszczyk
> http://aniszczyk.org
> +1 860 839 2465
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev