You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2017/04/07 15:54:49 UTC
[DISCUSSION] Ver 3.0 coming...
Hi,
I want to push hard for a release at end of next week. I am looking through
the remaining 3.0 marked issues, and
Timeseries --> postpone
Entity = Identity+Value --> Postpone indefinitely (too much consequence)
Java 9 issues --> postpone, Java 9 is not out yet
Yeoman generator --> will complete
ORM --> just postponed, too much effort to release within weeks let alone
days.
Pluggable Types --> I don't know that status. Paul? Postpone if needed.
(POLYGENE-94)
Mapping in toEntity/toValue --> Will investigate, possibly implement
otherwise postpone.
Rhino -> javax.scripting --> working on it.
Jar Signing --> I don't know, and look at Paul the build master for
opinion. (POLYGENE-116)
OSGi not working --> Postpone (I am secretly giving up on OSGi)
Cocnerns/SideEffect on methods --> I will investigate, test and document if
it works. Otherwise postpone.
POLYGENE-121 + 122 --> would like to fix, IF I knew better what you meant.
POLYGENE-132 --> Might be a big one. I have not fully understand what Kent
was concluding, but might be important.
Indexing-SQL --> Really tough one. I don't think I have enough time to fix
this. So, do we cut it out of the release and revive it later? Or is there
someone volunteering to take a stab at it?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [DISCUSSION] Ver 3.0 coming...
Posted by Niclas Hedhman <ni...@hedhman.org>.
It has been good couple of mornings, and most smaller issues for 3.0 has
been ticked off.
And that lands us with ONE issue left, and that is the Indexing-SQL one.
I will take another stab at it now, but if I can't figure this out, I am
inclined to drop dev-status to 'beta' and it will not be released. Any and
all help is highly appreciated.
On Sat, Apr 8, 2017 at 5:17 AM, Paul Merlin <pa...@apache.org> wrote:
> Hey,
>
> Yay for the upcoming 3.0-RC1!
>
>
> Le 2017-04-07 17:54, Niclas Hedhman a écrit :
>
>> Hi,
>> I want to push hard for a release at end of next week. I am looking
>> through
>> the remaining 3.0 marked issues, and
>>
>> Timeseries --> postpone
>>
>
> OK
>
> Entity = Identity+Value --> Postpone indefinitely (too much consequence)
>>
>
> We can look at this one in very different ways and see small increments
> that can give us some goodness without eating the whole cake. What I would
> like us to do quickly, and preferably for 3.0, is to change how Entity
> state is serialized in our EntityStore SPI helpers.
>
> Today, the "value" part of an EntityState is mixed with entity aspects:
>
> {
> reference: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> properties: {..},
> associations: {..},
> manyassociations: {..},
> namedassociations: {..}
> }
>
> I'm thinking about persisting entities with the following structure
> instead:
>
> {
> identity: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> value: { // Exact same state (de)serialization as values
> myProperty: {..},
> myAssoc: "..",
> myManyAssoc: [..],
> myNamedAssoc: {..}
> }
> }
>
> This is quite simple to change, simplifies a lot of code and I'm willing
> to push that forward rather quickly.
> I already have a local experiment of this change.
> BUT, this is a breaking change of the storage format so before doing so
> I'd like to know what do you all think.
> 3.0 is a good time to do this. Don't want to wait for 4.0. If we want to
> push a version out prior to that change, then it should be a -ALPHA1
> instead of a -RC1.
>
> Java 9 issues --> postpone, Java 9 is not out yet
>>
>
> OK, everything works without Jigsaw already
> There's only the Riak client that does not support Java 9 yet.
>
> Yeoman generator --> will complete
>>
>
> If we release the generator to npm we need to sort out how to do that the
> ASF way.
>
> ORM --> just postponed, too much effort to release within weeks let alone
>> days.
>>
>
> OK
>
> Pluggable Types --> I don't know that status. Paul? Postpone if needed.
>> (POLYGENE-94)
>>
>
> I answered directly on the issue. Please follow up there.
>
> Mapping in toEntity/toValue --> Will investigate, possibly implement
>> otherwise postpone.
>>
>
> This should not be too complicated, but we can also postpone to 3.1 as an
> API enhancement.
>
> Rhino -> javax.scripting --> working on it.
>>
>
> Cool
>
> Jar Signing --> I don't know, and look at Paul the build master for
>> opinion. (POLYGENE-116)
>>
>
> Postpone! It may be a bit of a can of worms.
>
> OSGi not working --> Postpone (I am secretly giving up on OSGi)
>>
>
> I personally don't use OSGi at all and don't care much.
>
> Cocnerns/SideEffect on methods --> I will investigate, test and document if
>> it works. Otherwise postpone.
>>
>
> OK
>
> POLYGENE-121 + 122 --> would like to fix, IF I knew better what you meant.
>>
>
> Those are minor enhancements we can do in 3.1.
>
> POLYGENE-132 --> Might be a big one. I have not fully understand what Kent
>> was concluding, but might be important.
>>
>
> Kent?
>
> Indexing-SQL --> Really tough one. I don't think I have enough time to fix
>> this. So, do we cut it out of the release and revive it later? Or is there
>> someone volunteering to take a stab at it?
>>
>
> Stan?
>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [DISCUSSION] Ver 3.0 coming...
Posted by Niclas Hedhman <ni...@hedhman.org>.
According to the mail archive
https://lists.apache.org/list.html?dev@polygene.apache.org, the attachment
didn't go through, so time for some ASCII rendering...
25
| .
20 /
| .......
15 /
| |
10 |
| |
5 ...... +++++++++
| / /
++++++++++++++++---------
where;
+ : line of added issues
. : line of fixed issues
24 issues resolved, 4 created
:-)
The chart will eventually disappear from
https://issues.apache.org/jira/browse/POLYGENE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
On Mon, Apr 10, 2017 at 2:01 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> I hope the attachment on this email is not stripped...
>
> On Sat, Apr 8, 2017 at 5:17 AM, Paul Merlin <pa...@apache.org> wrote:
>
>> Hey,
>>
>> Yay for the upcoming 3.0-RC1!
>>
>>
>> Le 2017-04-07 17:54, Niclas Hedhman a écrit :
>>
>>> Hi,
>>> I want to push hard for a release at end of next week. I am looking
>>> through
>>> the remaining 3.0 marked issues, and
>>>
>>> Timeseries --> postpone
>>>
>>
>> OK
>>
>> Entity = Identity+Value --> Postpone indefinitely (too much consequence)
>>>
>>
>> We can look at this one in very different ways and see small increments
>> that can give us some goodness without eating the whole cake. What I would
>> like us to do quickly, and preferably for 3.0, is to change how Entity
>> state is serialized in our EntityStore SPI helpers.
>>
>> Today, the "value" part of an EntityState is mixed with entity aspects:
>>
>> {
>> reference: "..",
>> application_version: "..",
>> type: "..",
>> version: "..",
>> modified: "..",
>> properties: {..},
>> associations: {..},
>> manyassociations: {..},
>> namedassociations: {..}
>> }
>>
>> I'm thinking about persisting entities with the following structure
>> instead:
>>
>> {
>> identity: "..",
>> application_version: "..",
>> type: "..",
>> version: "..",
>> modified: "..",
>> value: { // Exact same state (de)serialization as values
>> myProperty: {..},
>> myAssoc: "..",
>> myManyAssoc: [..],
>> myNamedAssoc: {..}
>> }
>> }
>>
>> This is quite simple to change, simplifies a lot of code and I'm willing
>> to push that forward rather quickly.
>> I already have a local experiment of this change.
>> BUT, this is a breaking change of the storage format so before doing so
>> I'd like to know what do you all think.
>> 3.0 is a good time to do this. Don't want to wait for 4.0. If we want to
>> push a version out prior to that change, then it should be a -ALPHA1
>> instead of a -RC1.
>>
>> Java 9 issues --> postpone, Java 9 is not out yet
>>>
>>
>> OK, everything works without Jigsaw already
>> There's only the Riak client that does not support Java 9 yet.
>>
>> Yeoman generator --> will complete
>>>
>>
>> If we release the generator to npm we need to sort out how to do that the
>> ASF way.
>>
>> ORM --> just postponed, too much effort to release within weeks let alone
>>> days.
>>>
>>
>> OK
>>
>> Pluggable Types --> I don't know that status. Paul? Postpone if needed.
>>> (POLYGENE-94)
>>>
>>
>> I answered directly on the issue. Please follow up there.
>>
>> Mapping in toEntity/toValue --> Will investigate, possibly implement
>>> otherwise postpone.
>>>
>>
>> This should not be too complicated, but we can also postpone to 3.1 as an
>> API enhancement.
>>
>> Rhino -> javax.scripting --> working on it.
>>>
>>
>> Cool
>>
>> Jar Signing --> I don't know, and look at Paul the build master for
>>> opinion. (POLYGENE-116)
>>>
>>
>> Postpone! It may be a bit of a can of worms.
>>
>> OSGi not working --> Postpone (I am secretly giving up on OSGi)
>>>
>>
>> I personally don't use OSGi at all and don't care much.
>>
>> Cocnerns/SideEffect on methods --> I will investigate, test and document
>>> if
>>> it works. Otherwise postpone.
>>>
>>
>> OK
>>
>> POLYGENE-121 + 122 --> would like to fix, IF I knew better what you meant.
>>>
>>
>> Those are minor enhancements we can do in 3.1.
>>
>> POLYGENE-132 --> Might be a big one. I have not fully understand what Kent
>>> was concluding, but might be important.
>>>
>>
>> Kent?
>>
>> Indexing-SQL --> Really tough one. I don't think I have enough time to
>>> fix
>>> this. So, do we cut it out of the release and revive it later? Or is
>>> there
>>> someone volunteering to take a stab at it?
>>>
>>
>> Stan?
>>
>>
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [DISCUSSION] Ver 3.0 coming...
Posted by Niclas Hedhman <ni...@hedhman.org>.
I hope the attachment on this email is not stripped...
On Sat, Apr 8, 2017 at 5:17 AM, Paul Merlin <pa...@apache.org> wrote:
> Hey,
>
> Yay for the upcoming 3.0-RC1!
>
>
> Le 2017-04-07 17:54, Niclas Hedhman a écrit :
>
>> Hi,
>> I want to push hard for a release at end of next week. I am looking
>> through
>> the remaining 3.0 marked issues, and
>>
>> Timeseries --> postpone
>>
>
> OK
>
> Entity = Identity+Value --> Postpone indefinitely (too much consequence)
>>
>
> We can look at this one in very different ways and see small increments
> that can give us some goodness without eating the whole cake. What I would
> like us to do quickly, and preferably for 3.0, is to change how Entity
> state is serialized in our EntityStore SPI helpers.
>
> Today, the "value" part of an EntityState is mixed with entity aspects:
>
> {
> reference: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> properties: {..},
> associations: {..},
> manyassociations: {..},
> namedassociations: {..}
> }
>
> I'm thinking about persisting entities with the following structure
> instead:
>
> {
> identity: "..",
> application_version: "..",
> type: "..",
> version: "..",
> modified: "..",
> value: { // Exact same state (de)serialization as values
> myProperty: {..},
> myAssoc: "..",
> myManyAssoc: [..],
> myNamedAssoc: {..}
> }
> }
>
> This is quite simple to change, simplifies a lot of code and I'm willing
> to push that forward rather quickly.
> I already have a local experiment of this change.
> BUT, this is a breaking change of the storage format so before doing so
> I'd like to know what do you all think.
> 3.0 is a good time to do this. Don't want to wait for 4.0. If we want to
> push a version out prior to that change, then it should be a -ALPHA1
> instead of a -RC1.
>
> Java 9 issues --> postpone, Java 9 is not out yet
>>
>
> OK, everything works without Jigsaw already
> There's only the Riak client that does not support Java 9 yet.
>
> Yeoman generator --> will complete
>>
>
> If we release the generator to npm we need to sort out how to do that the
> ASF way.
>
> ORM --> just postponed, too much effort to release within weeks let alone
>> days.
>>
>
> OK
>
> Pluggable Types --> I don't know that status. Paul? Postpone if needed.
>> (POLYGENE-94)
>>
>
> I answered directly on the issue. Please follow up there.
>
> Mapping in toEntity/toValue --> Will investigate, possibly implement
>> otherwise postpone.
>>
>
> This should not be too complicated, but we can also postpone to 3.1 as an
> API enhancement.
>
> Rhino -> javax.scripting --> working on it.
>>
>
> Cool
>
> Jar Signing --> I don't know, and look at Paul the build master for
>> opinion. (POLYGENE-116)
>>
>
> Postpone! It may be a bit of a can of worms.
>
> OSGi not working --> Postpone (I am secretly giving up on OSGi)
>>
>
> I personally don't use OSGi at all and don't care much.
>
> Cocnerns/SideEffect on methods --> I will investigate, test and document if
>> it works. Otherwise postpone.
>>
>
> OK
>
> POLYGENE-121 + 122 --> would like to fix, IF I knew better what you meant.
>>
>
> Those are minor enhancements we can do in 3.1.
>
> POLYGENE-132 --> Might be a big one. I have not fully understand what Kent
>> was concluding, but might be important.
>>
>
> Kent?
>
> Indexing-SQL --> Really tough one. I don't think I have enough time to fix
>> this. So, do we cut it out of the release and revive it later? Or is there
>> someone volunteering to take a stab at it?
>>
>
> Stan?
>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: [DISCUSSION] Ver 3.0 coming...
Posted by Paul Merlin <pa...@apache.org>.
Hey,
Yay for the upcoming 3.0-RC1!
Le 2017-04-07 17:54, Niclas Hedhman a �crit�:
> Hi,
> I want to push hard for a release at end of next week. I am looking
> through
> the remaining 3.0 marked issues, and
>
> Timeseries --> postpone
OK
> Entity = Identity+Value --> Postpone indefinitely (too much
> consequence)
We can look at this one in very different ways and see small increments
that can give us some goodness without eating the whole cake. What I
would like us to do quickly, and preferably for 3.0, is to change how
Entity state is serialized in our EntityStore SPI helpers.
Today, the "value" part of an EntityState is mixed with entity aspects:
{
reference: "..",
application_version: "..",
type: "..",
version: "..",
modified: "..",
properties: {..},
associations: {..},
manyassociations: {..},
namedassociations: {..}
}
I'm thinking about persisting entities with the following structure
instead:
{
identity: "..",
application_version: "..",
type: "..",
version: "..",
modified: "..",
value: { // Exact same state (de)serialization as values
myProperty: {..},
myAssoc: "..",
myManyAssoc: [..],
myNamedAssoc: {..}
}
}
This is quite simple to change, simplifies a lot of code and I'm willing
to push that forward rather quickly.
I already have a local experiment of this change.
BUT, this is a breaking change of the storage format so before doing so
I'd like to know what do you all think.
3.0 is a good time to do this. Don't want to wait for 4.0. If we want to
push a version out prior to that change, then it should be a -ALPHA1
instead of a -RC1.
> Java 9 issues --> postpone, Java 9 is not out yet
OK, everything works without Jigsaw already
There's only the Riak client that does not support Java 9 yet.
> Yeoman generator --> will complete
If we release the generator to npm we need to sort out how to do that
the ASF way.
> ORM --> just postponed, too much effort to release within weeks let
> alone
> days.
OK
> Pluggable Types --> I don't know that status. Paul? Postpone if needed.
> (POLYGENE-94)
I answered directly on the issue. Please follow up there.
> Mapping in toEntity/toValue --> Will investigate, possibly implement
> otherwise postpone.
This should not be too complicated, but we can also postpone to 3.1 as
an API enhancement.
> Rhino -> javax.scripting --> working on it.
Cool
> Jar Signing --> I don't know, and look at Paul the build master for
> opinion. (POLYGENE-116)
Postpone! It may be a bit of a can of worms.
> OSGi not working --> Postpone (I am secretly giving up on OSGi)
I personally don't use OSGi at all and don't care much.
> Cocnerns/SideEffect on methods --> I will investigate, test and
> document if
> it works. Otherwise postpone.
OK
> POLYGENE-121 + 122 --> would like to fix, IF I knew better what you
> meant.
Those are minor enhancements we can do in 3.1.
> POLYGENE-132 --> Might be a big one. I have not fully understand what
> Kent
> was concluding, but might be important.
Kent?
> Indexing-SQL --> Really tough one. I don't think I have enough time to
> fix
> this. So, do we cut it out of the release and revive it later? Or is
> there
> someone volunteering to take a stab at it?
Stan?