Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <CADmm+KeGR2UdzETWyEe5xjZBBBBY_f1gF+wKJYwrv7AHgN5M4w@mail.gmail.com>
References: <CADmm+Kd56fMG2kwgp50VxtBvfPCiVe-LjzFJ_aY_=_rVDS8vmA@mail.gmail.com>
 <88c4a1c0882a647e95b9d1932af0cfbe@nosphere.org> <CADmm+KeGR2UdzETWyEe5xjZBBBBY_f1gF+wKJYwrv7AHgN5M4w@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Mon, 10 Apr 2017 14:45:33 +0800
Message-ID: <CADmm+Ke+UbM23nvhFxz93koJf--1iJhZ3jWMdWU6MRrgFx_6Yw@mail.gmail.com>
Subject: Re: [DISCUSSION] Ver 3.0 coming...
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary=f403045ea640a4584e054cca5366
archived-at: Mon, 10 Apr 2017 06:45:58 -0000

--f403045ea640a4584e054cca5366
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=3Dcom.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 =C3=A9crit :
>>
>>> 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 =3D Identity+Value --> Postpone indefinitely (too much consequenc=
e)
>>>
>>
>> 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 wou=
ld
>> 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 th=
e
>> ASF way.
>>
>> ORM --> just postponed, too much effort to release within weeks let alon=
e
>>> 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 a=
n
>> 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 mean=
t.
>>>
>>
>> Those are minor enhancements we can do in 3.1.
>>
>> POLYGENE-132 --> Might be a big one. I have not fully understand what Ke=
nt
>>> 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
>


--=20
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

--f403045ea640a4584e054cca5366--