David,
your comments are very helpul. Thanks!
The only thing I could
not easy find was "regular builds" with evidence of "passing
test suites" -- and may well be there ... but I could not
easily see
any recent, regular builds, even at https://hudson.eclipse.org/paho/
.
The existing client libraries are pretty stable at the
moment. Yes, there are some enhancements that need to be put
into the main streams, but the libraries are pretty fully
functional as they are.
For non-Java environments I am struggling a bit with what
packaging means. For the C library, we have demand for Windows
and MacOS builds, but currently the Eclipse build infrastructure
does not support these, except the possibility of cross
compilation. Mike and Wayne have some disagreement about
whether those build environments should be supported: https://bugs.eclipse.org/bugs/show_bug.cgi?id=415757
Also, one of the requirements for simultaneous release inclusion
is "and be in a
build for the composite site aggregation by M4".
Can you explain what that means?
Thanks
Ian
On 29/11/13 21:26, David M Williams wrote:
From a "Simultaneous
Release"
point of view, yes ... you should go ahead and create it.
Technically,
to "join the Simultaneous Release" you should announce to
cross-project
list
(as well as subscribe to it :)
and for
that you need a "release record". See
http://waynebeaton.wordpress.com/2013/09/09/eclipse-luna-whos-in/
And you need to do so before "M4"
(which is 12/13).
[Technically, you can do later,
via
the "Exception Process" ... but seems like you have time to do
it by the deadline ... don't make any of the requested tasks
harder than
they need to me :) ]
On the topic of "incubation",
see
http://eclipse.org/projects/dev_process/#6_2_3_Incubation
in particular
http://wiki.eclipse.org/Development_Resources/HOWTO/Criteria_for_Graduating_from_Incubation_Phase_to_Mature_Phase
I initially asked about it in the
context
of "ready for production use or not" ... as an incubating
project
can (still) have a release but typically the "release number"
is below "1.0" ... such as "0.8" or something. And
while there is no formal statement about it, remaining in
"incubation
phase" when you release is sort of an implicit signal your code
"could
be used for production, but is a little less mature than
enterprise production",
in rough terms (which, again, are just my own words and
subjective view
... there's nothing formal about it).
In terms of the "Eclipse Process"
to graduate from incubation can be done at the same time as you
release
... though is a little more work as you need to document that
you are "ready
for graduation", etc. If there is any doubt in your minds, one
strategy
might be to have your "first release" (combined with a
graduation)
say in March of 2014 ... that would be "1.0" then have another
"release" in June, with the Luna train, that would mostly be
bug fixes and minor additions (and it'd be "1.1" ... just a few
short months later).
While this may sound like "more
work" ... overall it is probably easier, since it will spread
out
the work so each step is a little easier.
But if there is no doubt in your
minds,
you can combine the two and do "1.0" in June. Or, if you know
you are not "ready for formal graduation", you can just plan
for 0.8 in June, or similar.
In either case, to graduate, you
want
to demonstrate that you have regular "milestone" builds. I
assume
you have no literal dependencies on the rest of the "release
train"?,
but would be best to follow the same dates (which has milestones
about
once every 6 weeks or so). See
https://www.google.com/calendar/embed?src="">
as well as the whole wiki at
http://wiki.eclipse.org/Luna
The point of "the Simultaneous
Release" (among other things) is that adopters know they can
depend
on certain dates and updates for early testing, etc. in addition
to the
actual final release and subsequent maintenance releases.
Lastly, it is "up to your PMC"
if you are ready for graduation, or not ... so you might want to
meet/discuss
with them on what the expectations are ... perhaps with a
outline of why
you think you are ... say in January, or so. (Each PMC is a
little different,
and I'm not that familiar with projects graduating in Technology
PMC).
But, from a quick skim read of your forum and bugzilla
component, I'd say
you are close to ready .... if not already ready. The only thing
I could
not easy find was "regular builds" with evidence of "passing
test suites" -- and may well be there ... but I could not easily
see
any recent, regular builds, even at https://hudson.eclipse.org/paho/
. Perhaps related, the "Git history" seemed to be kind of slow
lately (again ... all from a very quick skim read from me). And,
ideally,
you'd have "evidence of adoption" ... even if just for research
projects or informal device work (does not have to be in a
commercial product
or anything). None of this is meant as any sort of criticism,
I'm just
saying its hard for me to tell at a glance if you are ready for
graduation
from incubation, or not.
But, even if not ready for
graduation,
I would encourage you to work towards a release ... there's
nothing like
deadlines to make sure work gets done! :)
Let me know if/when you have more
specific
questions -- and hope my wordy comments are helpful.
Thanks,
From:
Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To:
General development
discussions for paho project <paho-dev@xxxxxxxxxxx>,
Date:
11/29/2013 11:06 AM
Subject:
Re: [paho-dev]
Release Planning for Paho - thoughts?
Sent by:
paho-dev-bounces@xxxxxxxxxxx
Andy, Dave,
I was thinking of a release with the MQTT standard support in it
at least.
Maybe another before that.
Shall I go ahead and create a release document in the project
database
https://projects.eclipse.org/projects/technology.paho
so we can plan it? Initial target date?
Ian
On 28/11/13 17:37, Andy Piper wrote:
On Thu, Nov 28, 2013 at 2:57 PM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
No, we've not had any releases yet. But in my
opinion,
the Java, C and _javascript_ clients are ready for production use,
and I
would talk to Roger about the Python client. We are getting
regular
bug reports for the Java and C clients.
Agreed.
We have dallied on a lot of this stuff, partly as
newcomers
and partly due to the range of interests and languages we are
balancing,
but I think the whole team of committers (at least those who
regularly
join the checkpoint calls) agree that we want to make a formal
release
signalling readiness for production use, at least in the cases
of some
clients.
We are also interested in being part of the release
train
for Luna in particular to promote our participation in the
broader Eclipse
M2M ecosystem. It looks like we should jump in to some of the
cross-project
mailing list discussions as Wayne suggests!
--
Andy Piper | Kingston upon Thames, London (UK)
blog: http://andypiper.co.uk
| skype: andypiperuk
twitter: @andypiper | images: http://www.flickr.com/photos/andypiper
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|
