polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [DISCUSSION] Ver 3.0 coming...
Date Mon, 10 Apr 2017 06:45:33 GMT
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 <niclas@hedhman.org> wrote:

> I hope the attachment on this email is not stripped...
>
> On Sat, Apr 8, 2017 at 5:17 AM, Paul Merlin <paulmerlin@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message