[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… <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, best practices for code movement (branching or integration); continuous integration and testing; build and configuration of software; build system maintenance; testing and reporting infrastructures; infrastructure as code; package and dependency management; legal sign-off and bill of materials; software deployment and delivery; code signing and certificate management; continuous delivery, deployment, installation, and updates; feature toggles or flags; cloud provisioning and management; interaction with mobile-app stores; principles and automated techniques for release planning; release engineering for product-line systems; DevOps and interaction with developers, users, and so on; multiplatform release engineering; release engineering for safety-critical systems (healthcare, automotive, and so on); experience reports on adoption of modern release-engineering techniques; and pipeline security or testing. 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(a)computer.org <mailto: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 <http://www.computer.org/software/author.htm> For submission details: software(a)computer.org <mailto:software@computer.org>To submit an article: https://mc.manuscriptcentral.com/sw-cs <https://mc.manuscriptcentral.com/sw-cs>