Preparing the elm-package

[bartavelle]

I published a formatted version of the elm package for testing, but I do not know why my code samples are truncated :(

I will keep on testing with a pair of real life projects until all of this is stable enough.

[agrafix]

What exactly do you mean by truncated? Can you show an example?

[bartavelle]

In http://package.elm-lang.org/packages/bartavelle/json-helpers/1.0.0/Json-Helpers, look at the beginning of the chapter "Encoding schemes". The sum type has 3 members in the source code ...

[bartavelle]

I mean 3 constructors.

[agrafix]

Looks like a bug in elms documentation generator... :-/

[bartavelle]

I have pushed a usable version of the elm package. I also have just pushed some changes in the elm-bridge package. I believe it is now releasable on hackage!

There are still pain points (for example I don't like how I created an ElmOptions type to account for newtype declarations, it probably should be decided during the json generation!).

What do you think ?

[agrafix]

A very important change would be to document somewhere which elm library in which version is needed to be compatible. Could you also update the example? Apart from that I think we can cut another release. Please add your self as author the license and cabal file :-)

[bartavelle]

Done!

[bartavelle]

If it's ok with you I'll add it to stackage as soon as the release is made.

[bartavelle]

Or perhaps I will not as the aeson bug isn't fixed yet :(

[agrafix]

Is our needed aeson version to high?

[bartavelle]

The currently required version is 0.9., but nightly now uses 0.10.. I am waiting for the new release because it contains a blocking bug ...

[agrafix]

Could you reference the aeson issue here?

[bartavelle]

haskell/aeson#293

[bartavelle]

I suppose the stack issue itself is : haskell/aeson#328

[agrafix]

I'll still release this to hackage and then we can make a minor release as soon as the stack issue is resolved.

[bartavelle]

Sounds good to me!

[bartavelle]

It will probably not be a minor release though, as the Options field has changed in 0.10.*!

A solution to this would be to alter the code right now, drop the ElmOptions type, and find a nice API to decide when to newtype stuff.

[agrafix]

Sadly I'm currently not using this library anymore (We switched to https://github.com/typed-wire/typed-wire ), so it's up to you what will suit you best for your usecase. It would be cool if you could provide release notes for this release? :-)

[bartavelle]

Let's wait on it a bit, I will do the refactoring in a few days and figure out a solution. I didn't realize this typed-wire project existed!

What did you have in mind for the release notes ? A changelog-like new file in the repo ?

[agrafix]

Yes, a changelog file would be great, just something so I can write up notes like this: https://github.com/agrafix/Spock/releases

[bartavelle]

I just pushed a very succint changelog. Is that what you had in mind? The way newtypes are handled is now independant of instance generation, so aeson Option type is all that is needed. This means it will be possible to upgrade to later versions with a minor version bump.

[agrafix]

Cool thank's! So we are ready for release? :-)

[bartavelle]

I sure am!

[agrafix]

Release is up on hackage :-) Do you want to make the announcement?

[bartavelle]

great!