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