reproduce-devel
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]