Its "new" as of last April.
And, by all means ... fix bugs and then submit a maintenance release for
final version (which would not need a "new release").
"Released", in this context, means the formal Eclipse process of having
been through the required release review which is always required of new
releases.
From: Doug Schaefer <dschaefer@xxxxxxx>
To: "cross-project-issues-dev@xxxxxxxxxxx"
<cross-project-issues-dev@xxxxxxxxxxx>,
"cross-project-issues-dev@xxxxxxxxxxx"
<cross-project-issues-dev@xxxxxxxxxxx>,
Date: 08/14/2013 11:33 AM
Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release
review
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
Yeah actually that doesn't make sense. Why have the release sit around
for a month instead of fixing bugs in it right to the end of the SR?
Sent from my BlackBerry 10 smartphone on the Rogers network.
*From: *Igor Fedorenko
*Sent: *Wednesday, August 14, 2013 11:24 AM
*To: *cross-project-issues-dev@xxxxxxxxxxx
*Reply To: *Cross project issues
*Subject: *Re: [cross-project-issues-dev] Question on Kepler SR1 release
review
Is "new releases must be released a month before SR RC1" a new
requirement?
--
Regards,
Igor
On 2013-08-14 6:53 PM, David M Williams wrote:
> I'll take this topic as a good segue to summarize Planning Council's
> view on "more frequent releases" and "including new features in SRs".
> I'll try to keep in brief, but anyone is welcome to read my full notes
> of meeting at _http://wiki.eclipse.org/Planning_Council/August_7_2013_
>
> First, it was recognized our "slow pace" was not satisfying all
projects
> and adopters, but ...
> Second, it was satisfying most, so the short answer is status quo
> continues ... though we committed to continue the discussion for the
> long term. Its just that no one knew of any "easy answers" that
could be
> implemented easily, without requiring more work from everyone.
>
> The "status quo" is captured in our current policy statement, at
>
_http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F_
>
>
> In fact, it turns out several strategic adopting members were
surprised
> we allow new features at all ... and wanted the emphasis to stay on
bug
> fixes and quality improvements in the SRs, and to not "be
surprised" by
> new features. So, we humbling ask projects to announce and summarize
> here on cross-project list when they are adding new features and when
> "minor" versions increment. We definitely want to allow projects
to add
> new features when they need to, based on the needs of their community
> and adopters ... but don't want to encourage "experiments" with new
> features that might not be fully baked yet. So, we'll stick with the
> restrictions that "new releases" must be released a month before
RC1 and
> "be in" RC1, as our policy states.
>
> This does not prevent any project from having a new release anytime
you
> want .... but might mean you can not contribute it to "Simultaneous
> Release maintenance".
>
> Hope this helps adds clarity to the current rules for "Simultaneous
> Release maintenance".
>
> Thanks,
>
>
>
>
> From: Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
> To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
> Date: 08/14/2013 08:55 AM
> Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release
> review
> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
>
------------------------------------------------------------------------
>
>
>
> Am 14.08.2013 um 02:41 schrieb Matthias Sohn
<matthias.sohn@xxxxxxxxx>:
> > AFAIK if you want to release a pure maintenance release (only
> bugfixes, no new features)
> > you don't need a release review, if you want to ship new features
you
> need the review.
>
> Yes, this is correct. Technically, a pure maintenance (aka. service)
> releases changes only the 'x' of 'a.b.x' version string.
>
> -Gunnar
>
> --
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx
>
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> _https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev________________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev