[Apologies for duplicate reception of this CFP]

IEEE Software Special Issue on Release Engineering 3.0
https://www.computer.org/software-magazine/2016/12/14/release-engineering-3-0-call-for-papers/


Submission deadline: 1 August 2017

Publication: Mar./Apr. 2018


Whereas software used to be released in shrink-wrapped form, the advent of the Web and agile methodologies has totally changed the landscape. For example, lean startups such as IMVU continuously deliver their software up to 50 times per day, and companies such as Intuit, Google, and Mozilla take only a couple of hours or days between releases. Even Mozilla Firefox releases every six weeks, generating updates for dozens of versions on a variety of platforms for more than 80 locales. In other words, releasing modern applications requires coordinating their release on multiple mobile platforms, Web platforms with centralized backend services, and native desktop clients.

Software release engineering is the discipline of integration, build, test execution, deployment, and delivery of high-quality software releases to users. In particular, independently developed software components must be integrated such that all of them form a coherent whole. The integrated components (a mixture of textual source code and binary libraries) must be transformed into a working set of executables (a build system). The executables must be tested, deployed into the production environment (cloud, app store, download site, and so on), and eventually released to the user’s device of choice. These activities form the vital link between a software product’s design and development and the finished product’s use and maintenance. However, they require specialized skills and automation that all too often are classified as outside the scope of software engineering research.

Large software companies such as Google, Facebook, and Netflix have been pioneering release-engineering technologies and practices, and that journey has been risky and costly. Even at this point, these companies aren’t sure about the long-term viability or deficiencies of practices such as continuous delivery or canary deployment, especially in today’s migration toward hundreds of interdependent yet autonomously updated microservices. All of this makes it difficult for small companies, startups, civic organizations, government administrations, and safety-critical industries (healthcare, automotive systems, and so on) to select and adopt a release-engineering process and tool chain that fits their needs. An out-of-the-box release-engineering process and tool chain is far from a reality, as are textbooks or experience reports with empirically validated best practices for release engineering.


So, this IEEE Software theme issue focuses on Release Engineering 3.0. Release Engineering 1.0 and 2.0 refer, respectively, to the traditional ad hoc and today’s highly automated release-engineering processes for general-purpose software systems. Release Engineering 3.0 targets the future iteration of release-engineering processes aimed at supporting small companies, startups, civic organizations, government administrations, and safety-critical industries. For example, the software in cars, hospital equipment, or election software needs updates to deliver critical bug fixes and new functionality. However, without proper precautions, innocent people’s lives could be at stake.

We seek experience reports and articles on tools, methods, practices, and techniques to streamline Release Engineering 3.0. Topics include, but aren’t limited to,
Several guest editors are release engineers, and one-third of the reviewers will be release engineers. So, we guarantee that each submission will receive at least one review from a practitioner.

Besides seeking regular-length articles (see the section “Submission Guidelines), we also seek short experience reports (2,500 to 3,000 words) from practitioners. These reports don’t need to make a research contribution but should instead present the experiences of a practitioner or practitioners by describing things such as the current release processes used, challenges faced, solutions attempted, and results obtained.


Submission Guidelines

Manuscripts must not exceed 3,000 words including figures and tables, which count for 250 words each. Submissions exceeding these limits might be rejected without refereeing. Articles deemed within the theme and scope will be peer reviewed and are subject to editing for magazine style, clarity, organization, and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the theme issue for which you’re submitting.

Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments aren’t appropriate. Articles should be novel. IEEE Software doesn’t republish material published previously in other venues, including other periodicals and formal conference or workshop proceedings, whether previous publication was in print or electronic form. For more information, contact the guest editors at software2a-2018@computer.org.


Theme Issue Guest Editors
  • Bram Adams, Polytechnique Montreal

  • Stephany Bellomo, SEI
  • Christian Bird, Microsoft Research
  • Boris Debíc, Google
  • Foutse Khomh, Polytechnique Montreal
  • Shane McIntosh, McGill University
  • Kim Moir, Mozilla
  • John O’Duinn, US Digital Service


For general author guidelines: www.computer.org/software/author.htm
For submission details: software@computer.org
To submit an article: https://mc.manuscriptcentral.com/sw-cs