I think that we can make this work. But you need to accept that
there is some process that needs to be done. The release process is
an important and necessary part of the Eclipse Development Process.
What you're doing right now is effectively becoming an end-run
around the process. We need to figure out a reasonable way to
conform to the spirit of the process.
I have no issue with the project producing a milestone build every
4-6 weeks. This is perfectly reasonable. Those milestones really do
need to be building up to something that we'll brand as a proper
release. According to the EDP, milestone builds are really intended
for developer testing and for adopters to prepare for the eventual
release, as a opposed to something that is intended for general
consumption. This might be something that we can consider changing
to better accommodate runtime projects.
We need to figure out the right fit for Vert.x. Many projects do an
annual release; some biannual. Others release more frequently. A
full-bore release every 4-6 weeks is rare (EGit did this for a
while). You might look to Jetty for inspiration. Minimally, though,
I'd like to see Vert.x do a proper release at least annually.
We might, for example consider a model where Vert.x produces an
official release once a year, and produces milestones on a six week
cycle leading up to that release. Many (perhaps even most) projects
do this today. You might consider pushing out some service releases
after the main release, but--again--that's up to you.
With this in mind, I'd like for you to put a stake in the ground.
When will the first official EDP release of Vert.x be produced?
Engage with your mentors to get help with the documentation
requirements.
Wayne
On 03/12/2014 12:32 PM, Tim Fox wrote:
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
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|
