Cumulus MX 4.0

[galfert]

Are we really just 4 releases away from Cumulus MX 4.0? Currently we sit with version 3.9.6.

Hmmmm... Will 4.0.0 be special or different? If there is nothing on the planning board to role out a significant new feature, I propose at least a visual element change. Just to commemorate reaching version 4.0.0. I don't want a radical change. I like how Cumulus MX looks so I wouldn't want to mess it up. But some element of tackful redesign might be nice, as long as it still looks and acts like Cumulus MX.

Food for thought.

Maybe for the interim we increase the build numbers but keep the version number the same for small future updates. Then we reserve the big 4.0 for a great reveal.

[HansR]

You can also use 3.10.0 etc... after 9 comes 10, not a requirement to go to 4.
So you can go a long time on version 3
Agreed 4 is large upgrade.

[ConligWX]

Indeed, 3.10 could be an option, though I hope no matter what, Twitter feed gets a mention sometime soon

[mcrossley]

though I hope no matter what, Twitter feed gets a mention sometime soon

Argh!!!!! Nooo, its too hard!

[ConligWX]

though I hope no matter what, Twitter feed gets a mention sometime soon

Argh!!!!! Nooo, its too hard!

Hell then - lets start talking about CumulusMX v5

[sfws]

Before Steve Loft first made his beta MX code available (October 2018), there were about 8 people who told Steve Loft that, if he released his source code, they would solve all the bugs his beta had, and produce a wonderful piece of software.... Some of those were to be labelled as MX 4.0.

All these seemed so enthusiastic at first, but maybe they realised it needed a lot of work. Anyway, I guess all such ideas collapsed when, during 2020, Mark made so many changes to MX, nobody else could keep up with that pace of development (obviously Mark's source became a better starting point than Steve's source).

If you are interested, take a look at https://github.com/cumulusmx/CumulusMX/tree/v4.
There are many Cumulus projects on Github, I am unaware of any more that represent attempts to develop what was Steve Loft's software, but I suspect a few will be related work.

[HansR]

The last commit to v4 is 8 months ago. I don't see those guys here on the forum - or maybe they are in disguise? Are they still around?
The last time I looked I already could not follow what was being done and that has not improved.
What is the work break down, what is being used from v3, what is new, what is rewritten? What is the goal? Is there any documentation for others to join in?

I can see it is based on NET Core 3.1, which is definitely different than Framework, JSON library is different so there is a lot of divergence from v3.

Maybe some status update could be given? In a hidden thread if you do not wish the circle to be too large and discussion too wide.
What is the status? What will be the environment? What will be the input, output? Datastore? I understood v4 would be very different.
And if help is needed, it really needs a good work breakdown and project definition and management. Hand out work, receive back, test and integration work.

Cooperation really requires some effort.

And in the end: what would be the advantage of 4 over 3. In other words, maybe v3 is not all that bad after all Mark has done (to say the least). You might want to define some update work to v3 and then move it to v4 (or 5)

Above all: what is the goal of v4 over v3? Is it worth it?

I have more questions than answers for v4.

[sfws]

The last commit to v4 is 8 months ago

There is a newer commit on https://github.com/mcrossley/CumulusMX/tree/v4 that has been copied across to the V4 link I gave previously.

I have more questions than answers for v4.

I have neither questions, nor answers re any future developments. I focus on work around my property and not on what other people might be doing. My attitude to Cumulus remains that as the build I am running works, I will not download a newer release. I leave you, and other vocal contributors here to consider the future.

Before Steve Loft first made his beta MX code available (October 2018), there were about 8 people who told Steve Loft that, if he released his source code, they would solve all the bugs his beta had, and produce a wonderful piece of software.... Some of those were to be labelled as MX 4.0.

I don't see those guys here on the forum

If lockdown means you choose to search the forum posts for Northern Hemisphere Summer 2018, you should find posts that the various people made, that formed my vague recollections. Whether those are same people as in the github, I don't know, and don't care.

[HansR]

@sfws:
OK, thanks for replying. I understand you are not into v4 and the fact you wrote about v4 does not mean you are involved. I understand. But as this is a thread about v4, I thought it might be a good idea to discuss some things about it. Don't feel you have to answer all those remarks.

One thing I did not say yet is something about the datamodel.

In v3 there is a generic weather database (dayfile, monthly logs) which is the same for Davis and Ecowitt and the others.

But if it comes to extra sensors (and even Air Quality) the story becomes very different and the data model diverges on a device specific basis.
That might be a good topic to address in a next version (be it 4 or 5 or whatever).

Devices should be mapped on a device independent data model, the datastore should be switchable from the old text based to e.q. SQL based or other. Possibly with the accompanying query functions for the UI layer and beyond that to get data series for true data analysis for which webtags are somewhat limited (they inherently are).

Not sure what 4 is going to bring, anybody?

[HansR]

There is a newer commit on https://github.com/mcrossley/CumulusMX/tree/v4 that has been copied across to the V4 link I gave previously.

Tbh, now I am getting confused.

There is the repository cumulusmx / CumulusMX where Mark really is depositing the released CMX and which I monitor.
But apparently there is also a mcrossley /CumulusMX which is also being updated.

I am lost.
Anybody can shed a light? Why 2 CMX repositories?

[mcrossley]

Tbh, now I am getting confused.

There is the repository cumulusmx / CumulusMX where Mark really is depositing the released CMX and which I monitor.
But apparently there is also a mcrossley /CumulusMX which is also being updated.

I am lost.
Anybody can shed a light? Why 2 CMX repositories?

It's normal practice, there are a lot more than 2 CMX repositories. Everyone contributing forks the main repository, you make your updates to branches on your personal fork. Once you are happy, you create a pull request to the main master (if using master as the release)** to merge your changes. That way there is control on what is added, multiple users contribute without clashing (too much!) and you can specify only specific "admins" have the right to merge changes after reviewing them. Working directly on the main repo, and especially on the master is generally considered bad practice.

For v3 changes I am acting as both contributor and admin! For v4, my pull requests have to be reviewed.

** There are multiple ways of organising the repo, I've stuck with the simple "release from master", but other options include a branch for each major version etc. We use different strategies for different projects at work. Google "git workflow best practices"

[HansR]

Hi Mark, thanks for the reply. Yes the technique of pull requests is clear.
I got confused that two repositories were mentioned by sfws. Apparently only the cumulus / cumulus repo is the release repo (I assume). That means that is the one to fork and work with.

I am less confused.

[mcrossley]

Yes, cumulusmx/CumulusMX is the root repo that everything is merged into and holds the releases.

[galfert]

Well I guess that answers that. Cumulus MX 3.10.0 was just released. We'll be on 3.x numbering for the foreseeable future.