Taking the feedback, should we introduce support levels like we do with the
browser support policy?

* Level 1 - full support. We run automated testing for these platforms
  - amd64 versions of latest Windows and Windows Server versions, with the
latest GA update pack (we will need to specify editions in the final policy)
  - versions in our soon-to-be-official Docker packages (at the moment:
windowsservercore and nanoserver 1809)
* Level 2 - generally supported. We do not actively test it, but we intend
to keep compatibility, and we are happy to accept patches
  - Windows and Windows Server 64bit versions which are generally supported
by MS
* Level 3 - Best effort - We will consider patches if they do not put Level
1/2 support at risk and if they do not create bug maintenance overhead.
Support may have limitations and extra requirements. We do not test
compatibility, and we may drop support if there is a need
  - x86 and other non-amd64 architectures
  - "exotic" windows versions like Windows Embedded
  - Preview releases and updates by Microsoft
  - Windows API emulation systems like Wine or ReactOS
* Level 4 - Unsupported
  - Platforms and OS versions which are known to be incompatible or which
have severe limitations

Best regards,
Oleg




On Sat, Apr 11, 2020, 02:05 Daniel Beck <m...@beckweb.net> wrote:

>
>
> > On 10. Apr 2020, at 14:26, Oleg Nenashev <o.v.nenas...@gmail.com> wrote:
> >
> > I know for sure that there are Jenkins users running on Windows XP
>
> That's no reason to enable this insanity.
>
> I would advocate for just going with what's generally supported by
> Microsoft: Extended support would be in, "throwing bags of money at
> Microsoft" support is out, i.e. Windows 7 would have been unsupported since
> January.
>
> This approach would also address the problem of not having to manually
> keep the policy up to date. As we've seen with the browser support policy,
> nobody will update it.
> Additionally, this has the benefit of being fairly objective criteria, and
> would also save us from having to have this conversation again in two years.
>
> (And TBH I would just ignore Windows Embedded Industry, seems like a lot
> of effort for very few users.)
>
> Note also that this doesn't mean that Jenkins on these OSes would
> necessarily immediately break. If there's a new enough .NET Framework or
> whatever on Windows 7, and there's no reason to go with something newer,
> then Windows 7 will just continue to work. But users would know that they
> cannot indefinitely rely on it.
>
> Obviously I'm +1 for whatever makes it easier for you to support these
> components, even if it's just small steps.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/oK8pBCzPPpo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/C643B021-1451-4E76-921B-CD9543BA2C86%40beckweb.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDBoybSRFz4Lsmo_kynGT-BqknBPK%2BjGS87-tO5hZnnuw%40mail.gmail.com.

Reply via email to