Milestone 1.0.0 tracking bug

[RafaelKa]

0.3.0

[Holger-Will]

maybe we should bump a full version. As per semver we should do a full version upgrade if updates are not backwards compatible, wich they are not.

[Holger-Will]

i can not push a new version thought, could you do that, please? or npm owner add me ?

[RafaelKa]

or npm owner add me ?

done

---

I would propose to push over PRs inkl. reviews.

[Holger-Will]

yes, sorry. I did not wanted to bother you too much... i will work on my fork and create PRs when needed. thanks!

[Holger-Will]

what do you think is needed for an 1.0.0 ?

[RafaelKa]

what do you think is needed for an 1.0.0 ?

I think missing ESP3 Packet Types for which you created the issues.

[Holger-Will]

great! What about all the sub types? like all the common commands and their content? something for a later version?

[Holger-Will]

i know someone from the enocean alliance. he also send me the eep-xml file. i asked that guy to send me the esp3-xml file as well. If we get that, we can automate the whole process...

[RafaelKa]

Hi, feel free to add issues and add some related to milestone 1.0.0 I'll grap some ;)

Would propose to keep this issue open for discussions until 1.0.0 is bumped.

[Holger-Will]

@RafaelKa do you have access to a windows machine?

[RafaelKa]

@RafaelKa do you have access to a windows machine?

if inevitable needed, i can setup one. Why?

[Holger-Will]

I did get the source for the xml file, but you have to install DolphinView for it, and then you can find the file in the resource folder. Unfourtunatly Dolphin View comes as a windows installer exe... I can send you the installer.

[Holger-Will]

ok, found an old Win7 CD... setting up a VM now...

[Holger-Will]

damn... installed vbox, installed a win7 guest, installed the vbox guest extensions, installed .net, installed Dolphin View. Only to find there is no ESP.xml file... only the EEPs are available as an xml file... %"$§()"&§E% ... well back to hand writing then ;-)

[Holger-Will]

Mein Kontakt bei Enocean hat übrigens großes Interesse an unserem Projekt bekundet :-)

[RafaelKa]

Hi @Holger-Will, I seen you created few Repos on @node-enocean. Splitting the libs and dividing/distributing them by responsibility is correct approach. But I think we'll sink and waste much time on maintenance and difficult testing setups and scenarios. I would propose to discuss about mono-repo approach.

few things about: https://www.google.com/search?client=ubuntu&channel=fs&q=node+monorepo+pro+%26+contra&ie=utf-8&oe=utf-8

https://hackernoon.com/one-vs-many-why-we-moved-from-multiple-git-repos-to-a-monorepo-and-how-we-set-it-up-f4abb0cfe469

[Holger-Will]

this looks very interesting, indeed! great, now i have to read up on monorepos, as well ;-) ... i guess that everything connected to node-enocean should be living in the node-enocean repo then, right?

what about things like node-red-contrib-enocean or full blown app like DolphinView but written with electron and node-enocean should all this live there as well? or is it ok for those apps to live in their own repos but inside the node-enocean organisation? what do you suggest how to structure the mono repo properly?

[RafaelKa]

also, it depends and must be evaluated. Generally the mono-repos should contain all the things, which demand the collective changes on API changes and use the same build process(e.g. publishing on npm). Electron-app git repo could serve the "living alone" libs and publish them separately. So the App would dictate the strategy for libs, this makes sense sometimes IMHO, but usually the lib is required by the app and not vice versa.

[Holger-Will]

sounds good. I really want to get this going. if you are in on this i would create a new branch in node-enocean, delete all files and push this to master. then we have an empty repository to start with. what do you think?

[RafaelKa]

OK, lets do it.

[Holger-Will]

\o/ we are now enocean-js which is also the name of the monorepo please see discussion about how to mange this repo