Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Vert.x 2.1.0 release

Wayne-

Thanks for your reply.

I need to think about this and think about whether the Vert.x "release early, release often" approach really works with the Eclipse process, and if not, if there's anything we can do about it to make it less onerous.

The reality is, right now, this is not my top priority. My first priority is to keep the project moving along and progressing, and stuff like this, while it may be important to satisfy Eclipse rules is not something the Vert.x community really worries about. They want to see new features, better performance and for us to continue to compete with our competitors, so that's where I'd like to put my energy. I have spent too much time in recent weeks and months trying to figure out how all this stuff works to the detriment of project development.

So for now I'm going to just trundle on with milestones releases, as this seems the path of least resistance and people don't seem to mind using them. Some time in the future, if we can expand our very small team, hopefully we can put some resources onto dealing with this stuff. And hopefully I can delegate it, as I am personally really not cut out for this kind of work (you may have gathered already!)

On 12/03/14 15:38, Wayne Beaton wrote:

On 03/12/2014 11:22 AM, Tim Fox wrote:
AIUI Vert.x is an Eclipse project and we consume artifacts from Maven Central as part of our build. Is this wrong? All the dependencies have been IP checked so I don't see why this is an issue.

Strictly speaking... yes, it's wrong, and I think that I explained why. If you don't agree with my reasoning, we can use that as a basis for discussion.

I don't want this to be show-stopper. If the artefacts that get consumed in a build are *exactly* the same as what has been IP checked and approved, and you are absolutely certain that there is no risk of any unapproved artefacts sneaking into the build, then we can consider this an invalid intermediate state for the time being. As we move forward, we need to either get Vert.x building against the Eclipse Foundation-hosted Maven instance, or put the necessary energy into convincing the IP Team that building against Maven is acceptable (I'll need the PMC's assistance with the latter option).

FWIW, Thanh Ha can help you with the build (e.g. if there are required artefacts missing from our Maven instance. or POMs need to be updated).
Well.. this is the thing. The way we do releases is we try to do a release every 4-6 weeks. There are no "special themes" for releases. It just contains the next lot of stuff that is on the TODO list, which can be seen in Bugzilla. Some weeks we might two releases in a week.

The only way we can continue that model right now in the Eclipse process is to call each of those releases a "milestone" so we can fly under the radar, but to me a milestone release is really no different to a "proper" release.
There is another option. A service release does not require review. This would apply if you are not adding significant new functionality. If the release really just contains a bunch of bug fixes, you can simply create a release record, check the "service release" option, and push out your bits.

Service releases tend to increase the third-segment in the version number (e.g. 2.1.1), though there is no hard requirement for this.

If you do add API, or make other significant functionality changes, however, a full release and review is required.

As Mike stated earlier, we are game to review all of our processes. I look to the RT PMC for guidance.

Wayne
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon
            2014


_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc


Back to the top