[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[task #15698] New software (versions)
From: |
Mohammad Akhlaghi |
Subject: |
[task #15698] New software (versions) |
Date: |
Thu, 18 Jun 2020 13:25:22 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0 |
URL:
<https://savannah.nongnu.org/task/?15698>
Summary: New software (versions)
Project: Reproducible paper template
Submitted by: makhlaghi
Submitted on: Thu 18 Jun 2020 06:25:20 PM BST
Should Start On: Thu 18 Jun 2020 12:00:00 AM BST
Should be Finished on: Thu 18 Jun 2020 12:00:00 AM BST
Category: Software
Priority: 5 - Normal
Status: In Progress
Privacy: Public
Percent Complete: 30%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Effort: 0.00
_______________________________________________________
Details:
The versions of software used in Maneage will continue to evolve and we will
be adding new software continuously.
For example, in the last few months that we were mainly focused on the paper,
already almost all the basic software now have new versions, not to mention
many of the high-level ones!
But having single commits devoted to updating the version of a single
software, that is randomly distributed in the middle of other commits in the
core Maneage branch can be annoying for the readers who want to follow the
recent commits.
The updated software versions can also cause "semantic conflicts" due to some
updated/changed feature. So users have to be careful when updating software
versions. It would be much more easier for the users to only worry about one
commit rather than random commits scattered in the middle of other updates.
So I propose this solution: we keep a special branch on the development fork
project-dev <https://gitlab.com/maneage/project-dev>, dedicated to updating
software versions. When the number of new software reach 10 (just an arbitrary
number!) or more, we rebase that branch into the core Maneage branch as one
commit. The commit title can also be very clear for example starting with
"SOFTWARE VERSION UPDATE: ".
If a user wants to use the "bleeding edge" software that are not yet in the
'maneage' branch, they can simply merge the 'project-dev' branch into their
project and use that new version.
I have already started this proposed scenario with Raul's commit
<https://gitlab.com/maneage/project-dev/-/commit/82b4e0b3> to update the
version of Gnuastro in the new-software
<https://gitlab.com/maneage/project-dev/-/tree/new-software> branch.
In fact, if it is a high-level software, we can add it to this branch's
'TARGETS.conf' so it is tested by other people working on this branch
automatically. This will allow us to detect fast compilation bugs early
(before merging into the Maneage branch).
Note that this can include fundamentally new software also, not just updated
versions.
What do you think about this? Please share your thoughts here...
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/task/?15698>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
- [task #15698] New software (versions),
Mohammad Akhlaghi <=