branching etch for release 1.0.2, trunk is now release 1.1

["scott comer (sccomer)" <sc...@cisco.com>]

i've created a branch for etch release 1.0.2. 
https://svn.apache.org/repos/asf/incubator/etch/releases/release-1.0.2/

trunk is now open for 1.1 activities, the first of which will be the 
resolution of:

ETCH-22: Change Java (other?) package names to org.apache.etch

https://issues.apache.org/jira/browse/ETCH-22

the package name change will break code compatibility, but a recompile 
with the 1.1 compiler should be sufficient to resolve most issues. wire 
compatibility will not be compromised (except where any etch services' 
module name changes). so be it.

no other planning for 1.1 has occurred yet. to kick the ball, ideas for 1.1:

c binding (nearly done)
python binding (in progress)
reference etch services (naming, configuration, authentication, logging, 
router)
high performance transport using selectors (ETCH-10, ETCH-20)
interoptester (ETCH-15)

ideas? thoughts?

scott out

Re: branching etch for release 1.0.2, trunk is now release 1.1

["scott comer (sccomer)" <sc...@cisco.com>]

oh, by virtue of the evil plan powers vested in me, i've got a virtual 
lock on the trunk while
i change the package names. (click, thunk)

http://www.cksinfo.com/clipart/construction/tools/locks/lock.png

scott out

scott comer (sccomer) wrote:
> i've created a branch for etch release 1.0.2. 
> https://svn.apache.org/repos/asf/incubator/etch/releases/release-1.0.2/
>
> trunk is now open for 1.1 activities, the first of which will be the 
> resolution of:
>
> ETCH-22: Change Java (other?) package names to org.apache.etch
>
> https://issues.apache.org/jira/browse/ETCH-22
>
> the package name change will break code compatibility, but a recompile 
> with the 1.1 compiler should be sufficient to resolve most issues. 
> wire compatibility will not be compromised (except where any etch 
> services' module name changes). so be it.
>
> no other planning for 1.1 has occurred yet. to kick the ball, ideas 
> for 1.1:
>
> c binding (nearly done)
> python binding (in progress)
> reference etch services (naming, configuration, authentication, 
> logging, router)
> high performance transport using selectors (ETCH-10, ETCH-20)
> interoptester (ETCH-15)
>
> ideas? thoughts?
>
> scott out
>

Re: branching etch for release 1.0.2, trunk is now release 1.1

[James Dixson <di...@gmail.com>]

hrm.

Ok. I do not think the code is quite ready to be tagged just yet. I am
going to move "release-1.0.2" to "branches" and check it out. We
should not create tags under "releases" until we have a thumbs-up
consensus.

--
james




On Tue, Jan 27, 2009 at 3:44 PM, scott comer (sccomer)
<sc...@cisco.com> wrote:
> i've created a branch for etch release 1.0.2.
> https://svn.apache.org/repos/asf/incubator/etch/releases/release-1.0.2/
>
> trunk is now open for 1.1 activities, the first of which will be the
> resolution of:
>
> ETCH-22: Change Java (other?) package names to org.apache.etch
>
> https://issues.apache.org/jira/browse/ETCH-22
>
> the package name change will break code compatibility, but a recompile with
> the 1.1 compiler should be sufficient to resolve most issues. wire
> compatibility will not be compromised (except where any etch services'
> module name changes). so be it.
>
> no other planning for 1.1 has occurred yet. to kick the ball, ideas for 1.1:
>
> c binding (nearly done)
> python binding (in progress)
> reference etch services (naming, configuration, authentication, logging,
> router)
> high performance transport using selectors (ETCH-10, ETCH-20)
> interoptester (ETCH-15)
>
> ideas? thoughts?
>
> scott out
>
>

Re: branching etch for release 1.0.2, trunk is now release 1.1

[Niclas Hedhman <ni...@hedhman.org>]

On Tue, Jan 27, 2009 at 10:44 PM, scott comer (sccomer)
<sc...@cisco.com> wrote:

> no other planning for 1.1 has occurred yet. to kick the ball, ideas for 1.1:
>
> c binding (nearly done)
> python binding (in progress)
> reference etch services (naming, configuration, authentication, logging,
> router)
> high performance transport using selectors (ETCH-10, ETCH-20)
> interoptester (ETCH-15)

Well it depends on what is a reasonable timeline. "Release Early,
Release Often" is a mantra at ASF, although not all projects stick to
it.

So, if I were in your seat, I would take all the low hanging fruits
and kick out a 1.1 release in say 4-6 weeks. Until then, hopefully
some more ideas and work will approach 'low hanging', rinse and
repeat. Personally, I hope to get enough time to supply a patch for
'dynamic hook', once I am back @ home. Probably take a few laps of
questions, trial and error to get it right...


Cheers
Niclas
-- 
http://www.qi4j.org - New Energy for Java