post

How to watch for releases of upstream projects

Do you want to know when a new version of your favorite project is released? Do you want to make your job as packager easier? If so, this article is for you. It introduces you to the world of release-monitoring.org. You’ll see how it can help you catch up with upstream releases.

What is release-monitoring.org?

The release-monitoring.org is a combination of two applications: Anitya and the-new-hotness.

Anitya is what you can see when visiting release-monitoring.org. You can use it to add and manage your projects. Anitya also checks for new releases periodically.

The-new-hotness is an application that catches the messages emitted by Anitya. It creates a Bugzilla issue if the project is mapped to a Fedora package.

How to use release-monitoring.org

Now that you know how it works, let’s focus on how you can use it.

Index page of release-monitoring.org

First think you need to do is to log in. Anitya provides a few options you can use to log in, including the Fedora Account System (FAS), Yahoo!, or a custom OpenID server.

Login page

When you’re logged in, you’ll see new options in the top panel.

Anitya top panel

Add a new project

Now you can add a new project. It’s always good to check whether the project is already added.

Add project form

Next, fill in the information about the project:

  • Project name – Use the upstream project name
  • Homepage – Homepage of the project
  • Backend – Backend is simply the web hosting where the project is hosted. Anitya offers many backends you can chose from. If you can’t find a backend for your project, you can use the custom backend. Every backend has its own additional fields. For example, BitBucket has you specify owner/project.
  • Version scheme – This is used to sort received versions. Right now, Anitya only supports RPM version scheme.
  • Version prefix – This is the prefix that is stripped from any received version. For example, if the tag on GitHub is version_1.2.3, you would use version_ as version prefix. The version will then be presented as 1.2.3. The version prefix v is stripped automatically.
  • Check latest release on submit – If you check this, Anitya will do an initial check on the project when submitted.
  • Distro – The distribution in which this project is used. This could be also added later.
  • Package – The project’s packaged name in the distribution. This is required when the Distro field is filled in.

When you’re happy with the project, submit it. Below you can see how your project may look after you submit.

Project page

Add a new distribution mapping

If you want to map the project to a package on a specific distribution, open up the project page first and then click on Add new distribution mapping.

Add distribution mapping form

Here you can chose any distribution already available in Anitya, fill in the package name, and submit it. The new mapping will show up on the project page.

Automatic filing of Bugzilla issues

Now you created a new project and created a mapping for it. This is nice, but how does this help you as a packager? This is where the-new-hotness comes into play.

Every time the-new-hotness sees a new update or new mapping message emitted by Anitya, it checks whether this project is mapped to a package in Fedora. For this to work, the project must have a mapping to Fedora added in Anitya.

If the package is known, the-new-hotness checks the notification setting for this package. That setting can be changed here. The last check the-new-hotness does is whether the version reported by Anitya is newer than the current version of this package in Fedora Rawhide.

If all those checks are positive, the new Bugzilla issue is filed and a Koji scratch build started. After the Koji build is finished, the Bugzilla is updated with output.

Future plans for release-monitoring.org

The release-monitoring.org system is pretty amazing, isn’t it? But this isn’t all. There are plenty of things planned for both Anitya and the-new-hotness. Here’s a short list of future plans:

Anitya

  • Add libraries.io consumer – automatically check for new releases on libraries.io, create projects in Anitya and emit messages about updates
  • Use Fedora package database to automatically guess the package name in Fedora based on the project name and backend
  • Add semantic and calendar version scheme
  • Change current cron job to service: Anitya checks for new versions periodically using a cron job. The plan is to change this to a service that checks projects using queues.
  • Support for more than one version prefix

the-new-hotness

  • File Github issues for Flathub projects when a new version comes out
  • Create pull requests in Pagure instead of filing a Bugzilla issue
  • Move to OpenShift – this should make deployment much easier than how it is now
  • Convert to Python 3 (mostly done)

Both

  • Conversion to fedora-messaging – This is already in progress and should make communication between Anitya and the-new-hotness more reliable.

Photo by Alexandre Debiève on Unsplash.

post

Python 3.8 alpha in Fedora

The Python developers have released the first alpha of Python 3.8.0 and you can already try it out in Fedora! Test your Python code with 3.8 early to avoid surprises once the final 3.8.0 is out in October.

Install Python 3.8 on Fedora

If you have Fedora 29 or newer, you can install Python 3.8 from the official software repository with dnf:

$ sudo dnf install python38

As more alphas, betas and release candidates of Python 3.8 will be released, the Fedora package will receive updates. No need to compile your own development version of Python, just install it and have it up to date. New features will be added until the first beta.

Test your projects with Python 3.8

Run the python3.8 command to use Python 3.8 or create virtual environments with the builtin venv module, tox or with pipenv. For example:

$ git clone https://github.com/benjaminp/six.git
Cloning into 'six'...
$ cd six/
$ tox -e py38
py38 runtests: commands[0] | python -m pytest -rfsxX
================== test session starts ===================
platform linux -- Python 3.8.0a1, pytest-4.2.1, py-1.7.0, pluggy-0.8.1
collected 195 items

test_six.py ...................................... [ 19%]
.................................................. [ 45%]
.................................................. [ 70%]
..............................................s... [ 96%]
....... [100%]
========= 194 passed, 1 skipped in 0.25 seconds ==========
________________________ summary _________________________
py38: commands succeeded
congratulations 🙂

What’s new in Python 3.8

So far, only the first alpha was released, so more features will come. You can however already try out the new walrus operator:

$ python3.8
Python 3.8.0a1 (default, Feb 7 2019, 08:07:33)
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> while not (answer := input('Say something: ')):
... print("I don't like empty answers, try again...")
...
Say something:
I don't like empty answers, try again...
Say something: Fedora
>>>

And stay tuned for Python 3.8 as python3 in Fedora 31!

post

Fedora logo redesign

The current Fedora Logo has been used by Fedora and the Fedora Community since 2005. However, over the past few months, Máirín Duffy and the Fedora Design team, along with the wider Fedora community have been working on redesigning the Fedora logo.

Far from being just an arbitrary logo change, this process is being undertaken to solve a number of issues encountered with the current logo. Some of the issues with the current logo include the lack of a single colour variant, and, consequently the logo not working well on dark backgrounds. Other challenges with the current logo is confusion with other well-known brands, and the use of a proprietary font.

The new Fedora Logo design process

Last month, Máirín posted an amazing article about the history of the Fedora logo, a detailed analysis of the challenges with the current logo, and a proposal of two candidates. A wide ranging discussion with the Fedora community followed, including input from Matt Muñoz, the designer of the current Fedora logo. After the discussions, the following candidate was chosen for further iteration:

In a follow-up post this week, Máirín summarizes the discussions and critiques that took place around the initial proposal, and details the iterations that took place as a result.

After all the discussions and iterations, the following 3 candidates are where the team is currently at:

Join the discussion on the redesign over at Máirín’s blog, and be sure to read the initial post to get the full story on the process undertaken to get to this point.

post

Fedora Classrooms: Silverblue and Badge Design

Fedora Classroom sessions continue with two introductory sessions, on using Fedora Silverblue (February 7), and creating Fedora badges designs (February 10). The general schedule for sessions is availble on the wiki, along with resources and recordings from previous sessions. Details on both these upcoming sessions follow.

Topic: Fedora Silverblue

Fedora Silverblue is a variant of Fedora Workstation that is composed and delivered using ostree technology. It uses some of the same RPMs found in Fedora Workstation but delivers them in a way that produces an “immutable host” for the end user.  This provides atomic upgrades for end users and allows users to move to a fully containerized environment using traditional containers and flatpaks.

This session is aimed at users who want to learn more about Fedora Silverblue,
ostree, rpm-ostree, containers, and Flatpaks.  It is expected that attendees have some basic Linux knowledge.

The following topics will be covered:

  • What’s an immutable host?
  • How is Fedora Silverblue different from Fedora Workstation?
  • What is ostree and rpm-ostree?
  • Upgrading, rollbacks, and rebasing your host.
  • Package layering with rpm-ostree.
  • Using containers and container tools (podman, buildah).
  • Using Flatpaks for GUI applications

When and where

Instructor

Micah Abbott is a Principal Quality Engineer working for Red Hat. He remembers his first introduction to Linux was during university when someone showed him Red Hat Linux running on a DEC Alpha Workstation.  He’s dabbled with  various distributions in the following years, but has always had a soft spot for  Fedora. Micah has recently been contributing towards the development  of  Fedora/Red Hat CoreOS and before that Project Atomic.  He enjoys engaging with the community to help solve problems that users are facing and has most recently been spending a lot of time involved with the Fedora Silverblue community.

Topic: Creating Fedora Badges Designs

Fedora Badges is a gamification system created around the hard work of the Fedora community on the various aspects of the Fedora Project. The Badges project helps to drive and motivate Fedora contributors to participate in all different parts of Fedora development, quality, content, events, and stay active in community initiatives. This classroom will explain the process of creating a design for a Fedora Badge.

Here is the agenda for the classroom session:

  • What makes a Fedora Badge?
  • Overview of resources, website, and tickets.
  • Step by step tutorial to design a badge.

Resources needed:

  • Inkscape.
  • Comfortaa typeface.
  • Fedora badges resources (colour palettes, graphics, templates).

On Fedora, inkscape and comfortaa can be installed using dnf:

sudo dnf install inkscape aajohan-comfortaa-fonts

When and where

Instructor

Marie Nordin is a graphic designer and fine artist, with a day job as a Assistant Purchasing Manager in Rochester, NY. Marie began working on the Fedora Badges project and the Fedora Design Team in 2013 through an internship with the Outreachy program. She has maintained the design side of the Fedora Badges project for four years, as well as running workshops and teaching others how to  contribute designs to Badges.

post

3 simple and useful GNOME Shell extensions

The default desktop of Fedora Workstation — GNOME Shell — is known and loved by many users for its minimal, clutter-free user interface. It is also known for the ability to add to the stock interface using extensions. In this article, we cover 3 simple, and useful extensions for GNOME Shell. These three extensions provide a simple extra behaviour to your desktop; simple tasks that you might do every day.

Installing Extensions

The quickest and easiest way to install GNOME Shell extensions is with the Software Application. Check out the previous post here on the Magazine for more details:

Removable Drive Menu

Removable Drive Menu extension on Fedora 29

First up is the Removable Drive Menu extension. It is a simple tool that adds a small widget in the system tray if you have a removable drive inserted into your computer. This allows you easy access to open Files for your removable drive, or quickly and easily eject the drive for safe removal of the device.

Removable Drive Menu in the Software application

Extensions Extension.

The Extensions extension is super useful if you are always installing and trying out new extensions. It provides a list of all the installed extensions, allowing you to enable or disable them. Additionally, if an extension has settings, it allows quick access to the settings dialog for each one.

the Extensions extension in the Software application

Frippery Move Clock

Finally, there is the simplest extension in the list. Frippery Move Clock, simply moves the position of the clock from the center of the top bar to the right, next to the status area.

post

Mind map yourself using FreeMind and Fedora

A mind map of yourself sounds a little far-fetched at first. Is this process about neural pathways? Or telepathic communication? Not at all. Instead, a mind map of yourself is a way to describe yourself to others visually. It also shows connections among the characteristics you use to describe yourself. It’s a useful way to share information with others in a clever but also controllable way. You can use any mind map application for this purpose. This article shows you how to get started using FreeMind, available in Fedora.

Get the application

The FreeMind application has been around a while. While the UI is a bit dated and could use a refresh, it’s a powerful app that offers many options for building mind maps. And of course it’s 100% open source. There are other mind mapping apps available for Fedora and Linux users, as well. Check out this previous article that covers several mind map options.

Install FreeMind from the Fedora repositories using the Software app if you’re running Fedora Workstation. Or use this sudo command in a terminal:

$ sudo dnf install freemind

You can launch the app from the GNOME Shell Overview in Fedora Workstation. Or use the application start service your desktop environment provides. FreeMind shows you a new, blank map by default:

FreeMind initial (blank) mind map

A map consists of linked items or descriptions — nodes. When you think of something related to a node you want to capture, simply create a new node connected to it.

Mapping yourself

Click in the initial node. Replace it with your name by editing the text and hitting Enter. You’ve just started your mind map.

What would you think of if you had to fully describe yourself to someone? There are probably many things to cover. How do you spend your time? What do you enjoy? What do you dislike? What do you value? Do you have a family? All of this can be captured in nodes.

To add a node connection, select the existing node, and hit Insert, or use the “light bulb” icon for a new child node. To add another node at the same level as the new child, use Enter.

Don’t worry if you make a mistake. You can use the Delete key to remove an unwanted node. There’s no rules about content. Short nodes are best, though. They allow your mind to move quickly when creating the map. Concise nodes also let viewers scan and understand the map easily later.

This example uses nodes to explore each of these major categories:

Personal mind map, first level

You could do another round of iteration for each of these areas. Let your mind freely connect ideas to generate the map. Don’t worry about “getting it right.” It’s better to get everything out of your head and onto the display. Here’s what a next-level map might look like.

Personal mind map, second level

You could expand on any of these nodes in the same way. Notice how much information you can quickly understand about John Q. Public in the example.

How to use your personal mind map

This is a great way to have team or project members introduce themselves to each other. You can apply all sorts of formatting and color to the map to give it personality. These are fun to do on paper, of course. But having one on your Fedora system means you can always fix mistakes, or even make changes as you change.

Have fun exploring your personal mind map!


Photo by Daniel Hjalmarsson on Unsplash.

post

Build a Django RESTful API on Fedora.

With the rise of kubernetes and micro-services architecture, being able to quickly write and deploy a RESTful API service is a good skill to have. In this first part of a series of articles, you’ll learn how to use Fedora to build a RESTful application and deploy it on Openshift. Together, we’re going to build the back-end for a “To Do” application.

The APIs allow you to Create, Read, Update, and Delete (CRUD) a task. The tasks are stored in a database and we’re using the Django ORM (Object Relational Mapping) to deal with the database management.

Django App and Rest Framework setup

In a new directory, create a Python 3 virtual environment so that you can install dependencies.

$ mkdir todoapp && cd todoapp
$ python3 -m venv .venv
$ source .venv/bin/activate

After activating the virtual environment, install the dependencies.

(.venv)$ pip install djangorestframework django

Django REST Framework, or DRF, is a framework that makes it easy to create RESTful CRUD APIs. By default it gives access to useful features like browseable APIs, authentication management, serialization of data, and more.

Create the Django project and application

Create the Django project using the django-admin CLI tool provided.

(.venv) $ django-admin startproject todo_app . # Note the trailing '.'
(.venv) $ tree .
.
├── manage.py
└── todo_app
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py
1 directory, 5 files

Next, create the application inside the project.

(.venv) $ cd todo_app
(.venv) $ django-admin startapp todo
(.venv) $ cd ..
(.venv) $ tree .
.
├── manage.py
└── todo_app
├── __init__.py
├── settings.py
├── todo
│ ├── admin.py
│ ├── apps.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
├── urls.py
└── wsgi.py

Now that the basic structure of the project is in place, you can enable the REST framework and the todo application. Let’s add rest_framework and todo to the list of INSTALL_APPS in the project’s settings.py.

todoapp/todo_app/settings.py
# Application definition

INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'rest_framework',
'todo_app.todo',
]

 Application Model and Database

The next step of building our application is to set up the database. By default, Django uses the SQLite database management system. Since SQLite works well and is easy to use during development, let’s keep this default setting. The second part of this series will look at how to replace SQLite with PostgreSQL to run the application in production.

The Task Model

By adding the following code to todo_app/todo/models.py, you define which properties have a task. The application defines a task with a title, description and a status. The status of a task can only be one of the three following states: Backlog, Work in Progress and Done.

from django.db import models

class Task(models.Model):
STATES = (("todo", "Backlog"), ("wip", "Work in Progress"), ("done", "Done"))
title = models.CharField(max_length=255, blank=False, unique=True)
description = models.TextField()
status = models.CharField(max_length=4, choices=STATES, default="todo")

Now create the database migration script that Django uses to update the database with changes.

(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin makemigrations

Then you can apply the migration to the database.

(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin migrate

This step creates a file named db.sqlite3 in the root directory of the application. This is where SQLite stores the data.

Access to the data

Creating a View

Now that you can represent and store a task in the database, you need a way to access the data.  This is where we start making use of Django REST Framework by using the ModelViewSet. The ModelViewSet provides the following actions on a data model: list, retrieve, create, update, partial update, and destroy.

Let’s add our view to todo_app/todo/views.py:

from rest_framework import viewsets

from todo_app.todo.models import Task
from todo_app.todo.serializers import TaskSerializer


class TaskViewSet(viewsets.ModelViewSet):
queryset = Task.objects.all()
serializer_class = TaskSerializer

Creating a Serializer

As you can see, the TaskViewSet is using a Serializer. In DRF, serializers convert the data modeled in the application models to a native Python datatype. This datatype can be later easily rendered into JSON or XML, for example. Serializers are also used to deserialize JSON or other content types into the data structure defined in the model.

Let’s add our TaskSerializer object by creating a new file in the project todo_app/todo/serializers.py:

from rest_framework.serializers import ModelSerializer
from todo_app.todo.models import Task


class TaskSerializer(ModelSerializer):
class Meta:
model = Task
fields = "__all__"

We’re using the generic ModelSerializer from DRF, to automatically create a serializer with the fields that correspond to our Task model.

Now that we have a data model a view and way to serialize/deserialize data, we need to map our view actions to URLs. That way we can use HTTP methods to manipulate our data.

Creating a Router

Here again we’re using the power of the Django REST Framework with the DefaultRouter. The DRF DefaultRouter takes care of mapping actions to HTTP Method and URLs.

Before we see a better example of what the DefaultRouter does for us, let’s add a new URL to access the view we have created earlier. Add the following to todo_app/urls.py:

from django.contrib import admin
from django.conf.urls import url, include

from rest_framework.routers import DefaultRouter

from todo_app.todo.views import TaskViewSet

router = DefaultRouter()
router.register(r"todo", TaskViewSet)

urlpatterns = [
url(r"admin/", admin.site.urls),
url(r"^api/", include((router.urls, "todo"))),
]

As you can see, we’re registering our TaskViewSet to the DefaultRouter. Then later, we’re mapping all the router URLs to the /api endpoint. This way, DRF takes care of mapping the URLs and HTTP method to our view actions (list, retrieve, create, update, destroy).

For example, accessing the api/todo endpoint with a GET HTTP request calls the list action of our view. Doing the same but using a POST HTTP request calls the create action.

To get a better grasp of this, let’s run the application and start using our API.

Running the application

We can run the application using the development server provided by Django. This server should only be used during development. We’ll see in the second part of this tutorial how to use a web server better suited for production.

(.venv)$ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin runserver
Django version 2.1.5, using settings 'todo_app.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Now we can access the application at the following URL: http://127.0.0.1:8000/api/

DRF provides an interface to the view actions, for example listing or creating tasks, using the following URL: http://127.0.0.1:8000/api/todo

Or updating/deleting an existing tasks with this URL: http://127.0.0.1:8000/api/todo/1

Conclusion

In this article you’ve learned how to create a basic RESTful API using the Django REST Framework. In the second part of this series, we’ll update this application to use the PostgreSQL database management system, and deploy it in OpenShift.

The source code of the application is available on GitHub.

post

Carlos Castro León: How Do You Fedora?

We recently interviewed Carlos Castro León on how he uses Fedora. This is part of a series on the Fedora Magazine. The series profiles Fedora users and how they use Fedora to get things done. Contact us on the feedback form to express your interest in becoming a interviewee.

Who is Carlos Castro León?

Carlos Castro León is a computer engineer in northern Peru. He started using Linux in 2006 when another Linux user helped him install Ubuntu Edgy Eft. When Carlos attended college he decided to use a more stable distribution: “I already knew about Fedora 16 and decided to use it.” Castro León currently works as a computer engineer in Peru. His main task is to coordinate the activities of a team of individuals who manage the servers and networking at his company.

He loves food. He says his favorites are El Cabrito and La Caigua Rellena: “They are delicious and if you come to Peru I can give you very good recommendations.”

Carlos finds the most difficult thing is to get people interested in open source. He overcame resistance from his colleagues by building on the success of the first project. “My first project was implementing OpenVPN,” he says. After this he implemented the following servers: Zimbra, GLPI, DHCP, Rsync, Bacula, Owncloud, and Alfresco.

The Fedora Community

Castro León has some fantastic things to say about the Fedora Community: “They are always attentive to solve problems.”  He added, “the community documentation is available to everyone.” He would like to encourage the spread of open source. Carlos would like to create workshops, events and give presentations at universities. Castro León would like to see more people understand the full potential of having a computer engineering career within an open source project.

What Hardware?

Carlos owns a Dell Inspiron 15 5000 laptop with Fedora installed. He also uses a Brother DCP-T500W printer connected via wireless. “I have not had any issues with hardware or software compatibility,” he reports. For design work he uses a 20 inch monitor and extends the screen. At work he has a Lenovo M700 tiny. This computer has both Windows 10 and most importantly a Fedora install. Carlos says, “I prefer to use Fedora because it has better performance and I have not had problems connecting to shared resources within the office.”

What Software?

Castro León is currently running Fedora 29. For personal projects he uses GIMP, Inkscape, Kdenlive, Audacity, VLC and Simple Screen Recorder. At work he makes use of Shutter, Libre Office, GEdit, and Terminal.

post

Try the Dash to Dock extension for Fedora Workstation

The default desktop of Fedora Workstation — GNOME Shell — is known and loved by many users for its minimal, clutter-free user interface. However, one thing that many users want is an always-visible view of open applications. One simple and effective way to get this is with the awesome Dash to Dock GNOME Shell extension.

Dash to Dock takes the dock that is visible in the GNOME Shell Overview, and places it on the main desktop. This provides a view of open applications at a glance, and provides a quick way to switch windows using the mouse. Additionally, Dash to Dock adds a plethora of additional features and options over the built-in Overview dock, including autohide, panel mode, and window previews.

Features

Dash to Dock adds a bunch of additional features over the dock that usually shows in the GNOME Shell overview.

The extension has an intelligent autohide feature, that hides the dock when it obscures windows. To bring the dock back up, simply move the mouse to the bottom of the screen.

Additionally, panel mode stretches the dock to take up the entire width of the screen. This is a good option for users that want to always have the dock showing, without autohiding it.

Dash to Dock also cleanly handles multiple windows of the same application. It shows small dots under each application icon to show how many windows are open. Additionally, it can be configured to show previews of each window when clicking the icon, allowing the user to choose the window they want.

Installing Dash to Dock

The quickest and easiest way to install the extension is with the Software Application. Check out the previous post here on the Magazine for more details:

How to install extensions via the Software application

Note, however, that Dash to Dock is available in both the Fedora repositories, and via the GNOME Shell extensions repository. Consequently, it will show up twice when browsing for extensions in the Software application:

Typically, the version from GNOME Shell Extensions is kept up-to-date more frequently by the developer, so that version may be the safer bet.

Configuring Dash to Dock

The Dash to Dock extension has a wide range of optional features and tweaks that users can enable and change. Some of the tweakable items include: icon size, where to position the dock (including on multiple monitors), opacity of the dock, and themes.

Accessing the settings dialog for the extension is easy. Simply right-click on the applications icon in the dock, and choose Dash to Dock settings.

Note, however, that the extension allows you to remove the applications icon from the dock. In this case, access the settings dialog via the Software Application:

 

 

post

Fedora 27 End of Life

With the recent release of Fedora 29, Fedora 27 officially enters End Of Life (EOL) status on November 30, 2018. This impacts any systems still on Fedora 27. If you’re not sure what that means to you, read more below.

At this point, packages in the Fedora 27 repositories no longer receive security, bugfix, or enhancement updates. Furthermore, the community adds no new packages to the Fedora 27 collection starting at End of Life. Essentially, the Fedora 27 release will not change again, meaning users no longer receive the normal benefits of this leading-edge operating system.

There’s an easy, free way to keep those benefits. If you’re still running an End of Life version such as Fedora 27, now is the perfect time to upgrade to Fedora 28 or to Fedora 29. Upgrading gives you access to all the community-provided software in Fedora.

Looking back at Fedora 27

Fedora 27 was released on November 14, 2017. As part of their commitment to users, Fedora community members released about 9,500 updates.

This release featured, among many other improvements and upgrades:

  • GNOME 3.26
  • LibreOffice 5.4
  • Simpler container storage setup in the Fedora Atomic Host
  • The new Modular Server, where you could choose from different versions of software stacks

Fedora 27 screenshot

Of course, the Project also offered numerous alternative spins of Fedora, and support for multiple architectures.

About the Fedora release cycle

The Fedora Project offers updates for a Fedora release until a month after the second subsequent version releases. For example, updates for Fedora 28 continue until one month after the release of Fedora 30. Fedora 29 continues to be supported up until one month after the release of Fedora 31.

The Fedora Project wiki contains more detailed information about the entire Fedora Release Life Cycle. The lifecycle includes milestones from development to release, and the post-release support period.