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
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|