search

OpenEnergyPlatform / oeplatform

Repository for the code of the Open Energy Platform (OEP) website. The OEP provides an interface to the Open Energy Family
http://openenergyplatform.org/
GNU Affero General Public License v3.0
61 stars 19 forks source link

Release/0.9.1 #760

Closed christian-rli closed 2 years ago

christian-rli commented 3 years ago

Joint release in first OEP developer meeting.

Changes

Bugs

Features

christian-rli commented 3 years ago

@MGlauer : The release branch now contains the updated requirements and is ready for testing on toep. The latest commits don't show up in this PR. However they are in the release branch (https://github.com/OpenEnergyPlatform/oeplatform/tree/release/0.9.1) and here it says that that's enough. I also verified that info looking into another issue (https://github.com/github/hub/issues/198 "you don't need hub to update pull requests. Pull requests are tied to the remote branch they're opened from")

Please let @wingechr know when it's ready for testing and @wingechr please let me or both of us know when we can go on with the release :)

christian-rli commented 3 years ago

looks ok

Nice. Sorry for probing, but did you already test it on toep? I would just be impressed by the speed.

wingechr commented 3 years ago

looks ok

Nice. Sorry for probing, but did you already test it on toep? I would just be impressed by the speed.

only on my local system

MGlauer commented 3 years ago

First Feedback: The current version does not work with Django 3.0. but it does with version 3.2.. This should be amended in the requirements.txt

MGlauer commented 3 years ago

The test server has been updated

wingechr commented 3 years ago

First Feedback: The current version does not work with Django 3.0. but it does with version 3.2.. This should be amended in the requirements.txt

I think we should choose one of two options:

I assumend B) was already the case, but apparently not? This would also be my preferred option. Any thoughts?

christian-rli commented 2 years ago

I also prefer option B and thought that this was the case. So I'd suggest to go with that from now on.

MGlauer commented 2 years ago

There are arguments to make for both options. Option B guarantees that important security updates are installed as soon as they are available, but having the cutting edge version of any software package may introduce incompatibilites and even new security issues.

That is why most production environments settle with option A, in which you have a fixed set of packages that are thoroughly tested and work well together. Yet, there has to be some entity that keeps track of important security updates and manages necessary upgrades.

MGlauer commented 2 years ago

But this is probably something that should be discussed in a different place. Still, here is some read how different linux distributions handle this issue: https://averagelinuxuser.com/rolling-vs-fixed-linux-release/

christian-rli commented 2 years ago

There are arguments to make for both options. Option B guarantees that important security updates are installed as soon as they are available, but having the cutting edge version of any software package may introduce incompatibilites and even new security issues.

That is why most production environments settle with option A, in which you have a fixed set of packages that are thoroughly tested and work well together. Yet, there has to be some entity that keeps track of important security updates and manages necessary upgrades.

Thanks for the comments/explanation! I put it on the agenda for the next OEP DEV meeting.

christian-rli commented 2 years ago

I also tested moving tables now and the release can go on.

christian-rli commented 2 years ago

I checked the release description file, but final steps aren't fully described. What comes first - inform @MGlauer / merge into master / push release button? i'd be happy about a 3 line description or a quick call any time today.

MGlauer commented 2 years ago

Production has been updated