[Open-scap] OpenSCAP 1.2.0 coming soon

Sun Nov 2 22:56:54 UTC 2014

It would be great if the Release Schedule page also had information on the
RPM releases.

I'm also not sure where to look to find what is in each release. Here is
the information I have currently gathered. Since the wiki page indicates to
treat it as "RFC", I'm adding my comments here.

- The Current version of OpenSCAP is 1.1.1 (Sep 26, 2014)
- The Current RHEL package version of OpenSCAP is 1.0.8 (Jul 22, 2014)
- The Next feature release will be 1.2 scheduled for November 30, 2014
- Release Schedule: http://open-scap.org/page/Release_Schedule
- Version information can be found on http://open-scap.org/page/Download
- Roadmap information can be found at
https://fedorahosted.org/openscap/roadmap
- Source code is maintained on GitHub at
https://github.com/OpenSCAP/openscap
- Issues are still tracked on FedoraHosted.org
https://fedorahosted.org/openscap/report
- Archives are at: https://fedorahosted.org/releases/o/p/openscap/
- Versioning numbers explained: http://open-scap.org/page/Versioning

(Pasting table...)

    OS Package RPM Version RPM Date Committer From repo  RHEL 64-x86_64
openscap 1.0.8 Tue Jul 22 11:58:18 2014 Lubos Kocman <lkocman at redhat.com>
and Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
rhel-6-server-eus-rpms  CentOS 6.5-x86_64 openscap 1.0.8 Wed Sep  3
12:00:00 2014 Johnny Hughes <johnny at centos.org> base
I've also looked at Scap-security-guide (pasting table)

    OS Package RPM Version RPM Date Committer From repo  RHEL 64-x86_64
scap-security-guide 0.1.18 Thu Aug 28 12:00:00 2014 Jan iankko Lieskovsky <
jlieskov at redhat.com> rhel-6-server-rpms  CentOS 6.5-x86_64
scap-security-guide 0.1.18 Thu Aug 28 12:00:00 2014 Jan iankko Lieskovsky <
jlieskov at redhat.com> base

On Wed, Oct 29, 2014 at 12:01 PM, Martin Preisler <mpreisle at redhat.com>
wrote:

> Held a meeting with Simon to discuss this. Here are the notes.
>
> 1.2.0 is going to be released late November or early December. This allows
> us
> to include the OVAL 5.11 schema if it's released as scheduled. It also
> allows
> me to catch up with my changes.
>
> 1.1.x maintenance branch will be EOL-ed next year to lower maintenance
> costs.
> 1.0.x maintenance branch stays supported for the foreseeable future.
>
> Our optimistic plan is to make 2 feature releases per year in the future.
> I started a wiki page outlining this plan, see
> http://open-scap.org/page/Release_Schedule
> Comments welcome!
>
> Also updated due dates for the next 2 feature releases on the trac roadmap
> page,
> see https://fedorahosted.org/openscap/roadmap
>
> --
> Martin Preisler
>
> ----- Original Message -----
> > From: "Simon Lukasik" <slukasik at redhat.com>
> > To: "Martin Preisler" <mpreisle at redhat.com>
> > Cc: open-scap-list at redhat.com
> > Sent: Thursday, October 23, 2014 7:15:57 PM
> > Subject: Re: [Open-scap] OpenSCAP 1.2.0 coming soon
> >
> > On 10/23/2014 06:52 PM, Martin Preisler wrote:
> > > ----- Original Message -----
> > >> From: "Simon Lukasik" <slukasik at redhat.com>
> > >> To: "Martin Preisler" <mpreisle at redhat.com>
> > >> Cc: open-scap-list at redhat.com
> > >> Sent: Thursday, October 23, 2014 5:50:05 PM
> > >> Subject: Re: [Open-scap] OpenSCAP 1.2.0 coming soon
> > >>
> > >> Martin,
> > >>
> > >> I will try to find out, if I can live a few more weeks without
> upstream
> > >> release. I don't need new OpenSCAP just for playing or a showcase, I
> > >> have to have it in late November to productize things. The earlier I
> get
> > >> it the better.
> > >
> > > I would prefer an -rc release for now perhaps. But that probably
> wouldn't
> > > help.
> > >
> > >> So, I will try to build a development version in COPR environment,
> until
> > >> you resolve the issues you need to resolve.
> > >
> > > That would be great. I have re-planned some tasks and put higher
> priority
> > > on openscap changes.
> > >
> > >> Regardless, I have to disagree with the comments regarding the
> stability
> > >> of the new release. I simply don't understand them. You keep referring
> > >> to master branch as 'breaking release' or 'step back from responsible
> > >> upstream'; I am sorry that you feel it that way. I have tried hard to
> > >> not break things, I went extra mile when re-engineering the parsers
> > >> during September to ensure that there are no headaches going forward.
> > >
> > > This is simply a misunderstanding. I have no problems with your
> changes,
> > > I think they are great, as I have remarked many times. Currently I am
> > > having a hard time understanding why you came to this conclusion.
> > > It's almost impossible to make such big changes to the internals
> without
> > > breaking some use-case and you came pretty close. What I was getting at
> > > was the speed at which we are pushing out new feature releases.
> > > openscap 1.1.x will be very short-lived, don't you agree? We only
> > > released a single patch version!
> > >
> >
> > I agree, that maint-1.1 would be short-lived. And I agree that having
> > many maintenance branches would be overhead. Don't take me wrong, but up
> > to certain point I don't care if a branch is short lived or not.
> >
> > Instead, I try to optimize my workflow, and my best judgment told me to
> > release now. However, after your feedback it feels that my inner
> > judgment is not discounting the maintenance burden put on others.
> >
> > So here is the thought, what about dropping maint-1.1 after 1.2.0
> > release and maintain only maint-1.0, maint-1.2 and master branch?
> >
> > > I simply want to push for more long term planning, where long term
> > > doesn't mean 2 months. At this pace we will be maintaining tens of
> > > feature branches in a few years.
> > >
> > >> I am sorry that you are having hard times rebasing scap-workbench to
> new
> > >> API. I didn't dropped a single API call. I only deprecated couple of
> > >> them. I made sure to keep all the deprecated calls working. So, I am
> > >> surprised, there are problems.
> > >
> > > I am not having a hard time, but I am having "a time". As anyone who
> > > is using the API would. This is *absolutely normal* and expected.
> > >
> >
> > Happy to hear that! I've misunderstood your sentiment then.
> >
> > --
> > Simon Lukasik
> > Security Technologies, Red Hat, Inc.
> > https://github.com/isimluk
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/open-scap-list/attachments/20141102/6cd00028/attachment.htm>